[Pythonmac-SIG] pythonw

[Bob Ippolito]

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