[Pythonmac-SIG] pythonw vs. python

[Bob Ippolito]

On Feb 20, 2006, at 1:22 PM, Ronald Oussoren wrote:

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

Yeah, I've wanted this issue fixed since the beginning.  They really  
screwed this up, and haven't done a damn thing to fix it over the  
past 7 years or so.  Nothing we can do about that, though.

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

execv should be fast, and the startup of pythonw should be totally  
negligible.

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

Calling them at the start of Py_Main would likely work, but it can  
make the code hang for a ridiculously long time (on the order of  
several seconds) in my experience.  Not acceptable.  The execv is an  
acceptable hit, but this is not.

-bob