Develop Reference

Utilising bluetooth on Mac with Python

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.

How to fix dylib linking errors in an osx app generated with py2app? [duplicate]

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.

ImportError: Permission Denied while using LXML

I've been having a ton of trouble using LXML, after installing it from https://pypi.python.org/pypi/lxml/3.2.1 using Easy_Install-2.7. I installed it on Windows using cygwin, and at first the package seemed to be okay. However upon further testing I ran into problems.
When I run code with:
import lxml
it works completely fine. But as soon as I try:
import lxml.etree
I get this error:
Traceback (most recent call last):
File "D:\Nick_Code\NewsScraper\testdummy.py", line 7, in <module>
import lxml.etree
File "/usr/lib/python2.7/site-packages/lxml-3.2.0-py2.7-cygwin-1.7.20-i686.egg/lxml/etree.py", line 7, in <module>
__bootstrap__()
File "/usr/lib/python2.7/site-packages/lxml-3.2.0-py2.7-cygwin-1.7.20-i686.egg/lxml/etree.py", line 6, in __bootstrap__
imp.load_dynamic(__name__,__file__)
ImportError: Permission denied
I've been trying to find information/work arounds for quite a while but no success. Please let me know if you have any insight or need information.
Thanks!
Michael

This is not a solid answer. But I will highlight several of the problems involved for obtaining a solution. Most likely the problem above, is like a cancer caused by several factors acting catastrophically together.
I have the same exact problem as in the OP, when attempting to use the native Cygwin supplied Python packages on my Windows Vista machine. Being new to Python I have spent several days in trying to get this to work, and understand why it is not working. But all my Google-fu returned nothing but countless dead ends. So here's my take on this.
There are many reasons why Python could have trouble under Cygwin, some which you can do something about and some which are beyond most peoples control. What it boils down to, are the following key issues:
Windows is a complete mess when it comes to file permissions, and Cygwin cannot handle windows file permissions very well. So what you see in Cygwin is far from the whole story.
Windows is shamefully character case-independent which causes loads of trouble, especially when you need to (cross)compile anything that was originally developed under *nix based system (i.e. everything). In fact, if you attempt extracting any archive that contains files whose names differ only in capitalization. (I.e. "makefile" vs "Makefile" etc.) files under Windows or Cygwin, you loose all but one of the files. in case their You need to enable case-sensitivity to do anything more than "hello world" *nix compilations.
Windows handles symlinks completely different than Cygwin. And if your ZIP, TAR etc. archives contain any symlinks, they will be broken after extraction to Windows environment.
Sloppy code practices, where developer have not properly tested their creations on various environments, or carefully set proper file permissions to their *.tar.gz collections. Including correct dependency specifications, or mentioning whether or not binaries has been statically linked etc.
For the full gory details and further (Win-Cygwin) issues, look HERE.
At first I tried to use Cygwin's own Python without any additional packages, and nstalling lxml using PIP and easy_install. Then I tried to use Cygwin's own libxml2, libxslt and xml python packages, and I had the same problems.
At first, after installing the static windows binaries (as suggested elsewhere),
I got this error:
File "/usr/lib/python2.7/site-packages/lxml-3.2.4-py2.7-cygwin-1.7.24-i686.egg/lxml/etree.py", line 6, in __bootstrap__
imp.load_dynamic(__name__,__file__)
ImportError: Permission denied
Aborted (core dumped)
Then I investigated the file permissions and changed those with: chmod -R 755 /usr/lib/python2.7/
I got one step further to isolate problem to an apparently missing file.
And enabling verbose and diagnostic mode's didn't help much either.
File "/usr/lib/python2.7/site-packages/lxml-3.2.4-py2.7-cygwin-1.7.24-i686.egg/lxml/etree.py", line 6, in __bootstrap__
imp.load_dynamic(__name__,__file__)
ImportError: No such file or directory
Aborted (core dumped)
HERE is the exact statement specification:
Load and initialize a module implemented as a dynamically loadable shared
library and return its module object. If the module was already initialized, it
will be initialized again. Re-initialization involves copying the __dict__
attribute of the cached instance of the module over the value used in the module
cached in sys.modules. The pathname argument must point to the shared library.
The name argument is used to construct the name of the initialization function:
an external C function called initname() in the shared library is called. The
optional file argument is ignored. (Note: using shared libraries is highly
system dependent, and not all systems support it.)
So I started reading on the lxml website which clearly state lxml's dependencies on both libxml2 and libxslt, and unless they are statically linked, they also depend on iconv and zlib. So you're lead to believe you need to install all of these. Don't! Continue reading. But if you're going to build from sources (as easy_install may try to do) you'll need everything, including the development header libraries: libxml2-devel, libxslt-devel. Another place states that you also need Cython and install with:
easy_install lxml==dev
The dependencies are shown in this picture from HERE:
So you think you may get away with something like:
STATIC_DEPS=true pip install lxml
But that doesn't do it either. Probably because the libraries used to compile Cygwin's Python have to be the same as those for compiling lxml. But I don't know. Notice how the lxml package refers to Cygwin "1.7.24". My Cygwin is already "1.7.25" and you can check this with uname -a. Then you can check your static python executable with file and ldd. Then you understand that this also depend on the C-compiler used for building python/cygwin under Windows or *nix. Smelling a nightmare I decided that building my own was not the way to go. So next I tried to install the Python libraries (supplied as
executables) meant for Windows Python. This didn't work since I never had windows native Python installed, and I was greeted with an error that the installed could not find Python in my registry. I could of course just extract the executable, but I wouldn't know where to put the binaries without the installer. So I had another idea...
There are 3 possible solutions to getting this to work, as far as I can see.
The easy way of installing a Windows native Python interpreter. You loose some native Cygwin functionality, unless you install in correct place: /usr/lib/python2.7 and make sure Cygwin can find it and use it. This also uses a different file-permissions, case-sensitivity and character set (UTF-16LE) than Cygwin (UTF-8), potentially creating many other issues down the line! Difficulty: Easy
Continue hacking the Cygwin's Python, to make it work with the binary libraries used in (1). But this requires:
a) Uninstall and remove all Cygwin Python packages, except bare Python interpreter.
b) Remove all PIP and easy install traces.
c) Hacking the Windows registry to pretend to have Python27 installed:
HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\InstallPath C:\Python27\
HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\PythonPath C:\Python27\Lib;C:\Python27\DLLs;C:\Python27\Lib\lib-tk
HKEY_CLASSES_ROOT...
d) Install the Windows binary libraries.
e) All the rest should now hopefully work with PIP or easy_install. Difficulty: Medium!
Doing it properly by compiling Python and all libraries from scratch. Difficulty: Hard!
I successfully did (1), but I still think (2) is the smarter way of doing it, but I have not tested it, which is why I don't consider this as a good answer. BTW. One more quirk, I have to run the interpreter with: python.exe -E to avoid an annoying: "SyntaxError: invalid syntax" when hitting return!
Conclusion:
Apparently, you don't need the libxml2 and libxslt python packages to use lxml!
In my case I needed Scrapy, so I also had to install a few other packages.
$ pip.exe list
cssselect (0.9.1)
lxml (3.2.4)
pip (1.4.1)
pyOpenSSL (0.11)
pywin32 (218)
queuelib (1.1.1)
Scrapy (0.20.0)
setuptools (1.4.1)
six (1.4.1)
Twisted (13.2.0)
w3lib (1.5)
zope.interface (4.0.5)
$ll /cygdrive/c/Python27/Lib/site-packages/
adodbapi
cssselect
isapi
lxml
OpenSSL
pip
pythonwin
pywin32_system32
queuelib
scrapy
twisted
w3lib
win32
win32com
win32comext
zope
cssselect-0.9.1-py2.7.egg-info
lxml-3.2.4-py2.7.egg-info
pip-1.4.1-py2.7.egg-info
queuelib-1.1.1-py2.7.egg-info
Scrapy-0.20.0-py2.7.egg-info
six-1.4.1-py2.7.egg-info
Twisted-13.2.0-py2.7.egg-info
w3lib-1.5-py2.7.egg-info
zope.interface-4.0.5-py2.7.egg-info
PyWin32.chm
setuptools-1.4.1-py2.7.egg
pyOpenSSL-0.11-py2.7.egg-info
pywin32-218-py2.7.egg-info
easy-install.pth
pywin32.pth
setuptools.pth
zope.interface-4.0.5-py2.7-nspkg.pth
pythoncom.py
six.py
pythoncom.pyc
six.pyc
pythoncom.pyo
pywin32.version.txt
README.txt
Useful References:
HERE
HERE
HERE HERE HERE HERE
HERE

Python ArcGIS ArcPy RuntimeError: NotInitialized

Not sure if I am posting in the right place, but I am having problems getting my python GIS programs to work on Windows 7 64 bit. These programs worked on XP 32 bit. I've done a lot of research and tried changing my PythonPath, moving the lib folder, etc and other suggestions. I made a new key in the registry under Python26 as suggested by another with the contents of the Desktop10.pth file. However I am still getting the same error posted below. I am currently running ArcGIS 10.0. I am probably missing something simple! Any help would be greatly appreciated! Thank you in advance.
Traceback (most recent call last):
File "Z:\Desktop\GISClimateMapping.py", line 85, in
import arcpy
File "C:\Program Files (x86)\ArcGIS\Desktop10.0\arcpy\arcpy__init__.py", line
17, in
from geoprocessing import gp
File "C:\Program Files (x86)\ArcGIS\Desktop10.0\arcpy\arcpy\geoprocessing__in
it__.py", line 14, in
from _base import *
File "C:\Program Files (x86)\ArcGIS\Desktop10.0\arcpy\arcpy\geoprocessing_bas
e.py", line 568, in
env = GPEnvironments(gp)
File "C:\Program Files (x86)\ArcGIS\Desktop10.0\arcpy\arcpy\geoprocessing_bas
e.py", line 565, in GPEnvironments
return GPEnvironment(geoprocessor)
File "C:\Program Files (x86)\ArcGIS\Desktop10.0\arcpy\arcpy\geoprocessing_bas
e.py", line 521, in init
self._refresh()
File "C:\Program Files (x86)\ArcGIS\Desktop10.0\arcpy\arcpy\geoprocessing_bas
e.py", line 523, in _refresh
envset = (set(env for env in self._gp.listEnvironments()))
RuntimeError: NotInitialized

I had a very similar problem. We have a single licence which, if it's checked out to someone else, prohibits my script from running. I've found this empirically rather than through code/support but I'm fairly confident that's your issue.

You must use Python 2.6 32 bit with Arcgis 10.0, even with a 64 bit OS. I suspect (though not sure from the info provided) that you have another version of Python installed. I would first check to see how many versions are installed, and uninstall all of them except the one at C:\Pytho26\ArcGIS10.0. Then I'd install Python 2.6 (it's on the ArcGIS disk) at the location mentioned. You'll need to re-install numpy and matplotlib too, which are also on the disk. If that does not help, then I'd uninstall ArcGIS and every Python version on your machine, and then re-install ArcGIS. This sounds drastic, but ESRI's Python implementation is pretty sensitive, and you can waste days on trying to find an easy fix. This last step usually works.

I had this very error when the first line of my code was "import arcpy", and the solution for me was to insert a new first line to my python script: "import arcview".
My code was running fine on a system using ArcGIS 10.0, but ran into this problem after I upgraded my development box to 10.1 desktop and server. Various stackoverflow, gisstackexchange, and forums.arcgis.com articles pointed to PATH, PYTHONPATH, HLKM etc environment possibilities or checking your ArcGIS Administrator licensing. After reproducing the problem in both pyscripter and IDLE, confirming everything was as it should be with a properly uninstalled python 2.6, an installed python 2.7 environment, and a valid floating license the error still persisted. My best conjecture for why this fix worked is that perhaps starting with 10.1 arcgis license checkout may be more explicit.

For the record, I just encountered this problem in 10.1 while debugging an arcpy script in Visual Studio. It actually happened between runs with no code changes - one run worked, the next got the error. For whatever reason, adding the import arcview to the top worked. Maybe it is a license checkout issue, but such inconsistency is troubling.

Strange but true.
Had the same problem after upgrading ArcGIS (ArcInfo) 10.1 to 10.2.
Added one line in the python code:
import arcinfo
After this everything worked perfect. Easy to fix, hard to understand.
Thanks!
Willem

I think the problem was created by another user running ArcMap at the same time - since there is a single ArcGIS licence. When the user closed ArcMap in fact, the python script started running well.

This error might occur because your Python is 64-bit and your ArcMap 32-bit.
You can either update your python to a 64-bit version or update you ArcMap to a 64-bit.
How to get a 64-bit version of ArcMap:
From install. When you launch the autorun.exe application, the
startup window wil give you the option of installing ArcGIS Desktop
Background Geoprocessing (64-bit). This is only available in versions
10.1 and above
If you already have ArcGIS Installed in your computer. You can download a patch for the Background Geoprocessing (64-bit) here .

Python 2.5 zlib trouble

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).