A semi-related question; what is the current 'correct way' to package up Python projects and all their dependencies as native executables for Windows/OSX/Linux? I haven't done any desktop Python since 2.5 and then it was a fiddly process of 'freezing' exe's, is that still the recommended way with Python 3?
It sounds cynical, but I've found that porting Python code to C++ and using Qt is much less headache than trying to make a clean Python "app" that can be run by non-technical users. However a simple solution is to distribute a local copy of Python with all the packages pre-installed. That's not as clean as a single exe, but generally you're going to need DLLs or whatever anyway, and to the end user, running a bat file that calls Python hides most of the mess. The bigger problem with that is hiding code, if you need to do that, but you can always distribute pyc files on their own.
This may have changed, but the last time I tried freezing it took a lot of massaging to get it to work reliably. So I've always opted to just ship a complete python env. I've seen big commercial products do the same when they need to provide python support - you may have experienced this when some new install accidentally adds a new python interpreter to your PATH.
Between Qt and Python there is a huge amount of cross platform support. For example, I found out that Qt supports bluetooth, which currently has no other cross platform support in python (the unmaintained pybluez has all sorts of issues).
That's still the way to go, and it's still fiddly and always requires manual tweaking until it works. Especially on Linux. Deploying binaries on Linux is just always a hassle, and never works "everywhere"...
