On Feb 5, 2005, at 12:08 PM, Chris Fonnesbeck wrote:
Sorry in advance for what may, in fact, be a naive post, but I am trying to figure out the significance of pythonw on OSX. I know that you need to run pythonw if you intend to use python programs with certain graphical backends, otherwise the UI becomes unresponsive. Running idle from the command line, for example, starts an instance of idle that is unusable. My question is: why have both python and pythonw? When would you ever *not* want user interfaces not to work? This problem does not arise on other platforms, does it? Its a bit of a hassle, at the moment, to try and figure out when to use one or the other. Are there any plans to remove this apparently unnecessary dichotomy?
It is not possible to solve this problem without changing the way Python gets installed (making /usr/bin/python a fork-exec stub or shell script) or using private Apple SPI (to trick the WindowServer into doing the right thing).
As far as I know, other platforms do not have this problem.
The details of why this is aren't public because we don't have the source, however, the basic idea is that in order for the default WindowServer connection to be created correctly argv[0] needs to point to the absolute path of the executable, and that executable needs to be inside of an application bundle. /usr/bin/python is obviously not in an application bundle, and running "python foo.py" will leave argv[0] as a relative-to-$PATH path due to the way that the shell works. This is essentially a bug in the way WindowServer works, which I and others have filed bugs against, but Apple has neither opened an API to fix this nor have they fixed the bug in WindowServer.
The best fix that I can come up with is to make the GUI libraries for Python (Tkinter, wxPython, pygame, PyObjC, ...) hook into the private Apple SPI in a safe-ish way. In PyObjC proper, this isn't really an issue because it's not really useful to write PyObjC applications that aren't already in an application bundle. For the others, it is arguably useful. I have example code for doing this specific hack in PyObjC at <http://svn.red-bean.com/pyobjc/trunk/pyobjc/Examples/Scripts/ wmEnable.py>. I may add this hack to the next release of pygame (which is especially easy because pygame requires PyObjC), but the authors of Tk/Tkinter and wxPython are going to have to do it themselves. I have heard that some future version of Tk (which would directly fix Tkinter) may include an equivalent hack, but obviously the version of Tk that does this (if such a version is mainline) isn't very common yet.
For running your own scripts and playing around in the terminal, just use pythonw all the time. There is a very slight increase in start-up time, but nothing worth caring about.
-bob
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
