[Pythonmac-SIG] pythonw vs. python

[Bob Ippolito]

On Feb 20, 2006, at 9:56 AM, Ronald Oussoren wrote:

> I've been thinking a little about pythonw vs. python. The former is
> needed because on OSX any API that needs a connection to the window
> server (anything that uses a native GUI and some other calls) need to
> be in an application bundle. pythonw is a program that can be placed
> anywhere on the PATH and exec's a normal python interpreter inside an
> application bundle.
>
> As of yesterday the python24-fat tree[1] will install a copy of
> pythonw as the normal python interpreter, that is both 'python' and
> 'pythonw' are the same program, the one that execs an interpreter
> inside an application bundle. This works, but at the cost of
> additional call to exec and therefore two application startups. I
> guess the additional cost should be lost in the noise, but the micro-
> optimizer in me isn't happy and especially so because everybody pays
> while almost nobody should need this feature.

I'd rather eat the exec call than have to listen to endless drivel  
about these little differences between Mac OS X and other platforms.   
It shouldn't take very long to do that extra exec.  I'm frankly VERY  
tired of the FAQs and would like to silence as many as possible with  
our next build, even if that means a little performance hit or a  
little extra deviation from python.org sources.  In addition to this  
list, I also end up with personal email wrt MacPython, so this is an  
especially large nuisance for me.

The people that absolutely need the performance wouldn't be starting  
Python ad infinitum anyway, they'd be using daemons and/or forking.   
If anything, higher startup cost encourages people to do the right  
thing ;)

> The common workaround for this is the undocumented function
> 'CPSEnableForegroundOperation'. Another workaround might be the
> TransformProcessType API introduced in OSX 10.3.  Would it be
> worthwhile to look into these, or is it better to worry about other
> things instead.

The other reason not to do these things is that there's a lot of  
overhead to calling CPSEnableForegroundOperation and that it doesn't  
work after some amount of time.  IIRC, TransformProcessType doesn't  
work for this purpose.  I believe it still needs argv[0] to point  
inside of an application bundle.  It might be useful in "fixing" a  
process where it has waited too long before  
CPSEnableForegroundOperation.  I don't remember exactly, but the  
details aren't very interesting either way.

The pythonw-everywhere solution is a lot easier and more reliable  
than making these changes to every library that makes Carbon or Cocoa  
calls.

-bob