[Pythonmac-SIG] pythonw vs. python

[Ronald Oussoren]

On 20-feb-2006, at 19:51, Bob Ippolito wrote:

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

I agree that python and pythonw should both work for GUI code, it is  
something we can take care of and something new users keep running  
into. This is one issue where we really could blame Apple, but that  
doesn't help us very much. Annoyingly RTFM doesn't help a lot, nobody  
seems to read documentation ;-(

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

I don't care for higher startup costs for GUI scripts, those should  
use py2app anyway. Plain boring unix scripts worry me a bit more. But  
even there the startup cost should be neglectibable when compared  
with the total runtime. Luckily the new pythonw is a C program, which  
means the overhead is even smaller than it is in the current  
MacPython release.

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

If calling CPSEnableForegroundOperation or TransformProcessType at  
the start of Py_Main doesn't help I'm not interested. I'm convinced:  
I'm happy with the current python24-fat tree where python and pythonw  
are the same program.

Ronald