I've practically scoured the entire web (metaphorically speaking) trying to find a way to work with Bluetooth via Python on Mac. PyBluez is not compatible, Lightblue is not being maintained (tried regardless), installed the PyObC framework (incl Bluetooth Framework), and attempted in both my 2.7.6 and 3.6.1 environments with MacOS 10.10.5.
I often get errors similar to the below:
Traceback (most recent call last):
File "/Users/***/PycharmProjects/Bluey/main.py", line 1, in <module>
import bluetooth
File "build/bdist.macosx-10.10-intel/egg/bluetooth/__init__.py", line 47, in <module>
File "build/bdist.macosx-10.10-intel/egg/bluetooth/osx.py", line 1, in <module>
File "build/bdist.macosx-10.10-intel/egg/lightblue/__init__.py", line 160, in <module>
File "build/bdist.macosx-10.10-intel/egg/lightblue/_lightblue.py", line 31, in <module>
File "build/bdist.macosx-10.10-intel/egg/lightblue/_macutil.py", line 169, in <module>
objc.BadPrototypeError: Objective-C expects 1 arguments, Python argument has 2 arguments for <unbound selector sleep of BBCocoaSleeper at 0x103cdc030>
Process finished with exit code 1
I've also tried reinstalling all the aforementioned modules for both environments.
I just want to be able to work with Bluetooth w/o changing OSs for one project. I'm sure I've missed something since I doubt no-one codes for Bluetooth on Mac with Python. If there are inherent compatibility issues, is there another module that I have yet to discover?
There aren't any feature complete, updated, and fully working libraries for BLE in Python on macOS. The only one that works (but is very limited in functionality and not updated) is the Adafruit library here: https://github.com/adafruit/Adafruit_Python_BluefruitLE
You may want to try to use PyObjC (thats what the Adafruit library uses) to see if you can build your own BLE library/script.
I'd recommend (if you have to use macOS) is the Node.js library Noble: https://github.com/sandeepmistry/noble. Full-featured, works great and is continuously updated.
tabchas's answer is out of date. This library has been deprecated by Adafruit in favor of https://github.com/adafruit/Adafruit_Blinka_bleio which is not meant for general consumption.
However, it is built on https://github.com/hbldh/bleak which is active and cross platform, but is BLE-only.
Related
My question is simple: can I install win32com python API (pywin32 notably) on an OS that is not Windows?
I have been trying, on Mac, multiple versions of pip install pywin32, all have failed. An example below:
If you managed to install it on Linux I am also interested as I wrote it.
I am using python 3.7.8.
Thanks.
Win32COM is part of [GitHub]: mhammond/pywin32 - pywin32. According to the (above) URL, the package is only designed to work on Win:
Python for Win32 (pywin32) extensions
So, this is Win specific (it was never intended for other OSes).
As for your question, technically you could install it on Linux, or OSX (it is possible with some manual steps), but that would make absolutely no difference, because (even if installed) it would NOT run on those platforms, as it contains (consists of) binaries (.dlls) that don't run (can't be loaded by processes) on non Win OSes.
Just looked at the comments: [MS.Docs]: Office.MessageCompose interface is available on OSX, but (most likely, if there isn't already a Python wrapper available) you'd have to write the bindings yourself (their examples are in JS).
Additional (generic) information
Some packages are only meant to work in specific conditions, based on restricting criteria like:
Platform(s) (OS, CPU architecture)
Python version(s)
...
even if not enforced by the installation mechanism (meaning they can somehow end up "installed" on platforms that they don't work on).
Anyway, such restrictions are (should be) mentioned (example for PyWin32 - see the red boxes) in package's:
PyPI page
Homepage
Other resources (e.g.: package's doc page, if it has one)
Bottom line is that such a package will not work outside the conditions it was meant to run in (even if it can be installed), and more: when attempting to run it, will yield some error message that might not be very clear.
There are packages with such restrictions, but can be installed outside them:
Win:
ComTypes
Error:
[cfati#cfati-5510-0:/mnt/e/Work/Dev/StackOverflow/q064975918]> python -c "import comtypes"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/cfati/.local/lib/python3.8/site-packages/comtypes/__init__.py", line 28, in <module>
from _ctypes import COMError
ImportError: cannot import name 'COMError' from '_ctypes' (/usr/lib/python3.8/lib-dynload/_ctypes.cpython-38-x86_64-linux-gnu.so)
Fix (improvement): [GitHub]: enthought/comtypes - Improve error message on non Win
WConio2
Error:
[cfati#cfati-5510-0:/mnt/e/Work/Dev/StackOverflow/q064975918]> python -c "import WConio2"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/cfati/.local/lib/python3.8/site-packages/WConio2.py", line 125, in <module>
from ctypes import windll
ImportError: cannot import name 'windll' from 'ctypes' (/usr/lib/python3.8/ctypes/__init__.py)
Fix (improvement): [GitHub]: Solomoriah/WConio2 - Improve error message on non Win
I'm bundling a pygame app using py2app. The bundling works and the resulting bundle runs on my mac just fine. It also used to run on another person's mac just fine. However, recently I've started getting this error (from the console) when trying to run the bundle on his computer:
Traceback (most recent call last):
File "/Users/.../tmp/withconsole.app/Contents/Resources/__boot__.py", line 316, in <module>
_run()
File "/Users/.../tmp/withconsole.app/Contents/Resources/__boot__.py", line 311, in _run
exec(compile(source, path, 'exec'), globals(), globals())
File "/Users/.../tmp/withconsole.app/Contents/Resources/withconsole.py", line 18, in <module>
pdb.set_trace()
File "bdb.pyc", line 53, in trace_dispatch
File "bdb.pyc", line 88, in dispatch_return
File "pdb.pyc", line 190, in user_return
File "pdb.pyc", line 210, in interaction
File "cmd.pyc", line 142, in cmdloop
File "pdb.pyc", line 279, in onecmd
File "cmd.pyc", line 218, in onecmd
File "pygame/macosx.pyc", line 10, in <module>
File "pygame/sdlmain_osx.pyc", line 14, in <module>
File "pygame/sdlmain_osx.pyc", line 10, in __load
ImportError: dlopen(/Users/.../tmp/withconsole.app/Contents/Resources/lib/python2.7/lib-dynload/pygame/sdlmain_osx.so, 2): Symbol not found: _OBJC_CLASS_$_NSObject
Referenced from: /Users/.../tmp/withconsole.app/Contents/Resources/lib/python2.7/lib-dynload/pygame/sdlmain_osx.so
Expected in: /usr/lib/libobjc.A.dylib
in /Users/.../tmp/withconsole.app/Contents/Resources/lib/python2.7/lib-dynload/pygame/sdlmain_osx.so
2013-11-09 06:19:50.794 withconsole[2797:1c03] ogclient Error
I even tried running an older bundle that used to work, yet now it no longer works! I'm 95% certain of that, anyway.
In any case, what's the issue and how can I fix it?
A standalone app from py2app creates its baked-in Python interpreter from whichever version of Python you use for py2app.
If you use, say, a Python built to run on any OS X 10.6 or later, the application (so long as it doesn't use any post-10.6 features) will also run on any OS X 10.6 or later. If you use a Python built to run on one particular 10.8 machine, the application will very likely not work on anything earlier than 10.8, and may not even work on other 10.8+ machines.
On top of that, if you're using any C extension modules that you built against C libraries that you built yourself, if those C libraries were built for your particular machine, they'll probably cause the same problem.
You built your Python interpreter with Homebrew. And maybe your SDL as well, which pygame depends on. And possibly other things. By default, Homebrew builds everything to run on your particular machine, not to be redistributable. Hence the problem.
To build an app that can run on 10.7 machines, you need to either build Python, SDL, etc. against the 10.7 SDK, or build it against a later API and specify -mmacosx-version-min=10.7. (There are a few other issues that can come up, but I'm pretty sure none of them affect CPython, so let's keep it simple.)
That will automatically set things up so any C extension modules you build use the same SDK and version settings, so you shouldn't have to worry about those. But you do have to worry about any C libraries you built that those extension modules depend on. For example, pygame links against libSDL, and if you built SDL for your local machine only, pygame isn't going to work on someone else's machine.
It's possible to get Homebrew to create SDK builds, but not always that easy. It's easier to just build Python manually and pass the right --configure flags. But it's even easier to take a binary that someone else has already built for portability and use that.
The official Python installers at python.org are built for 10.6+. The official SDL development libraries are built for 10.5+. Hopefully the same is true for other things you're depending on. If so, just brew uninstall (or, if you're wary and want to be able to undo this later, brew unlink) everything, run the binary installers, reinstall all the Python modules you need for the new Python, and py2app with it.
I wrote this all in general terms. From the output, it looks like the specific problem you're hitting on this particular run on your friend's particular 10.7 machine is that the SDL wrappers are depending on features of the ObjC runtime that didn't exist in 10.7. So, it's possible that just using a 10.7-friendly SDL, and your existing Python, would be sufficient. But I think you're better off using 10.7-friendly everything if at all possible.
If you're wondering what exactly the SDK does, the SDK Compatibility Guide in Apple's official docs explain the technical side of it pretty well, and there are a zillion blog posts like this one that explain the practical parts, but I'll try to summarize.
Each SDK is just a directory that has its own /usr/include, /usr/lib, /System/Library/Frameworks, and a few other things inside. When you build against an SDK, you end up compiling against its header files instead of your system's, and linking against its dylibs instead of your system's. This prevents you from using any new features added since 10.6 (with a nice compiler error, instead of a successful build that then won't start on half your users' machines). And it makes sure that, if you don't use any such new features, your program doesn't have load-time dependencies on anything that didn't exist in 10.6.
I am trying to control an Agilent 33120A Arbitrary Waveform Generator using pyvisa under Ubuntu 13.04 (Raring Ringtail). I have installed and set up everything that is necessary to communicate with the instrument using our labs NI GPIB-USB-B adapter. The adapter firmware is loaded, and so are the kernel modules from linux-gpib.
I can successfully do some dry-runs, e.g. by running # ibtest (command-line tool), I can write *IDN? to the device, and I receive the device ID: 'HEWLETT-PACKARD,33120A,0,8.0-5.0-1.0'. I also tested other commands successfully, like setting voltage and frequency, and so on. It works.
The problem is, pyvisa always throws a VisaIOError... I have not clue how to get it to work. I run python-2.7 as root, so that (for now) I do not have to deal with any access privileges. This is the code and output:
import visa
>>> visa.vpp43.visa_library.load_library("/usr/lib/x86_64-linux-gnu/libvisa.so.0")
>>> visa.get_instruments_list()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.7/dist-packages/pyvisa/visa.py", line 254, in get_instruments_list
vpp43.find_resources(resource_manager.session, "?*::INSTR")
File "/usr/lib/python2.7/dist-packages/pyvisa/vpp43.py", line 583, in find_resources
instrument_description)
File "/usr/lib/python2.7/dist-packages/pyvisa/vpp43.py", line 398, in check_status
raise visa_exceptions.VisaIOError, status
pyvisa.visa_exceptions.VisaIOError: VI_ERROR_RSRC_NFOUND: Insufficient location information or the requested device or resource is not present in the system.
The library loads correctly. It is not even necessary, but I load the library explicitly to be safe. Obviously, pyvisa does not find any instrument. I also tried to explicitly open my instrument board=0, pad=10, sad=0 using either of these commands:
visa.instrument("GPIB::10")
visa.instrument("GPIB0::10")
visa.instrument("GPIB::10::0")
visa.instrument("GPIB0::10::0")
But the same exception as above is thrown.
Basically, everything is set up alright, but pyvisa does not see anything.
Used versions:
pyvisa-1.4
python-2.7
linux-gpib-3.2.20
libvisa-0.0.20130812-1 (https://launchpad.net/ubuntu/trusty/amd64/libvisa0/) newest build for Ubuntu 14.04 (Trusty Tahr) as this library is not in the repositories for Ubuntu 13.04)
I am hoping for some suggestions.
pyvisa is a Python wrapper around NI-VISA. As far as I know it's not possible to use pyvisa with linux-gpib. But linux-gpib comes with its own Python wrappers. Simply import Gpib and you're good to go, for example,
>>>import Gpib
>>>device = Gpib.Gpib(pad=10)
>>>device.write('*IDN?')
>>>device.read()
'HEWLETT-PACKARD,33120A,0,8.0-5.0-1.0'
I guess you're writing some kind of measurement script. Have a look at slave it might be usefull for you (disclaimer: I'm the author of slave). It tries to simplify the device communication. Also it comes with its own wrappers for linux-gpib.
I'm bundling a pygame app using py2app. The bundling works and the resulting bundle runs on my mac just fine. It also used to run on another person's mac just fine. However, recently I've started getting this error (from the console) when trying to run the bundle on his computer:
Traceback (most recent call last):
File "/Users/.../tmp/withconsole.app/Contents/Resources/__boot__.py", line 316, in <module>
_run()
File "/Users/.../tmp/withconsole.app/Contents/Resources/__boot__.py", line 311, in _run
exec(compile(source, path, 'exec'), globals(), globals())
File "/Users/.../tmp/withconsole.app/Contents/Resources/withconsole.py", line 18, in <module>
pdb.set_trace()
File "bdb.pyc", line 53, in trace_dispatch
File "bdb.pyc", line 88, in dispatch_return
File "pdb.pyc", line 190, in user_return
File "pdb.pyc", line 210, in interaction
File "cmd.pyc", line 142, in cmdloop
File "pdb.pyc", line 279, in onecmd
File "cmd.pyc", line 218, in onecmd
File "pygame/macosx.pyc", line 10, in <module>
File "pygame/sdlmain_osx.pyc", line 14, in <module>
File "pygame/sdlmain_osx.pyc", line 10, in __load
ImportError: dlopen(/Users/.../tmp/withconsole.app/Contents/Resources/lib/python2.7/lib-dynload/pygame/sdlmain_osx.so, 2): Symbol not found: _OBJC_CLASS_$_NSObject
Referenced from: /Users/.../tmp/withconsole.app/Contents/Resources/lib/python2.7/lib-dynload/pygame/sdlmain_osx.so
Expected in: /usr/lib/libobjc.A.dylib
in /Users/.../tmp/withconsole.app/Contents/Resources/lib/python2.7/lib-dynload/pygame/sdlmain_osx.so
2013-11-09 06:19:50.794 withconsole[2797:1c03] ogclient Error
I even tried running an older bundle that used to work, yet now it no longer works! I'm 95% certain of that, anyway.
In any case, what's the issue and how can I fix it?
A standalone app from py2app creates its baked-in Python interpreter from whichever version of Python you use for py2app.
If you use, say, a Python built to run on any OS X 10.6 or later, the application (so long as it doesn't use any post-10.6 features) will also run on any OS X 10.6 or later. If you use a Python built to run on one particular 10.8 machine, the application will very likely not work on anything earlier than 10.8, and may not even work on other 10.8+ machines.
On top of that, if you're using any C extension modules that you built against C libraries that you built yourself, if those C libraries were built for your particular machine, they'll probably cause the same problem.
You built your Python interpreter with Homebrew. And maybe your SDL as well, which pygame depends on. And possibly other things. By default, Homebrew builds everything to run on your particular machine, not to be redistributable. Hence the problem.
To build an app that can run on 10.7 machines, you need to either build Python, SDL, etc. against the 10.7 SDK, or build it against a later API and specify -mmacosx-version-min=10.7. (There are a few other issues that can come up, but I'm pretty sure none of them affect CPython, so let's keep it simple.)
That will automatically set things up so any C extension modules you build use the same SDK and version settings, so you shouldn't have to worry about those. But you do have to worry about any C libraries you built that those extension modules depend on. For example, pygame links against libSDL, and if you built SDL for your local machine only, pygame isn't going to work on someone else's machine.
It's possible to get Homebrew to create SDK builds, but not always that easy. It's easier to just build Python manually and pass the right --configure flags. But it's even easier to take a binary that someone else has already built for portability and use that.
The official Python installers at python.org are built for 10.6+. The official SDL development libraries are built for 10.5+. Hopefully the same is true for other things you're depending on. If so, just brew uninstall (or, if you're wary and want to be able to undo this later, brew unlink) everything, run the binary installers, reinstall all the Python modules you need for the new Python, and py2app with it.
I wrote this all in general terms. From the output, it looks like the specific problem you're hitting on this particular run on your friend's particular 10.7 machine is that the SDL wrappers are depending on features of the ObjC runtime that didn't exist in 10.7. So, it's possible that just using a 10.7-friendly SDL, and your existing Python, would be sufficient. But I think you're better off using 10.7-friendly everything if at all possible.
If you're wondering what exactly the SDK does, the SDK Compatibility Guide in Apple's official docs explain the technical side of it pretty well, and there are a zillion blog posts like this one that explain the practical parts, but I'll try to summarize.
Each SDK is just a directory that has its own /usr/include, /usr/lib, /System/Library/Frameworks, and a few other things inside. When you build against an SDK, you end up compiling against its header files instead of your system's, and linking against its dylibs instead of your system's. This prevents you from using any new features added since 10.6 (with a nice compiler error, instead of a successful build that then won't start on half your users' machines). And it makes sure that, if you don't use any such new features, your program doesn't have load-time dependencies on anything that didn't exist in 10.6.
I am trying to deploy an app on google app engine using bottle, a
micro-framework, similar to flask. I am running on ubuntu which comes
with python 2.7 installed but GAE needs version 2.5, so I installed
2.5. I then realized I didn't use make altinstall so I may have a
default version problem now. But my real problem is that when I try to
use the gae server to test locally I get the following error:
Traceback (most recent call last):
File "/opt/google/appengine/dev_appserver.py", line 77, in <module>
run_file(__file__, globals())
File "/opt/google/appengine/dev_appserver.py", line 73, in run_file
execfile(script_path, globals_)
File "/opt/google/appengine/google/appengine/tools/
dev_appserver_main.py", line 156, in <module>
from google.appengine.tools import dev_appserver
File "/opt/google/appengine/google/appengine/tools/
dev_appserver.py", line 94, in <module>
import zlib
ImportError: No module named zlib
Can you help me with this?
How did you build Python 2.5? If you built it from sources yourself, there's a good possibility the zlib module didn't get built because the necessary libraries and header files weren't installed on your system.
On Ubuntu, you need (I think) the zlib1g-dev package.
This will be true for a variety of other modules as well (for example, without the appropriate OpenSSL development libraries/headers in place, you won't get the ssl module either).
Someone may also have a python2.5 package for your version of Ubuntu (although neither Natty or Maverick appear to have one in the official repositories).
Before figuring out that using a post-2.5 Python worked just fine as long as you didn't use any post-2.5 language features or packages (or additions to package), I wrote up a walkthrough for building 2.5 for Ubuntu here. It includes the bit you need for zlib.
I'm now happily developing on Ubuntu using Python 2.6.5 (with SDK 1.5.4).