[Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?

[has]

Bill Janssen wrote:

> Chris, if you followed the thread, you'll know that what's happening  
> is
> that the Python.app app is being promoted to a "full app", without any
> provision for behaving like a "full app".  In particular, it doesn't
> participate in the various shutdown handshakes, and thus prevents  
> logout
> or shutdown.  This is pernicious.

No more pernicious than a similarly written AppleScript applet. If a  
Python script needs to respond to external desktop-level events, it  
should create its own event loop and drive its main logic off that  
event loop. 'while 1: do_everything()' just doesn't cut it in any  
event-driven environment.

As for automatically promoting scripts that require Window Manager  
access, the current behaviour is the correct one. It is more important  
that a script should succeed than be elegant. Elegance is nice to  
have, but irrelevant if the thing won't even launch. This is why the  
old python/pythonw distinction was done away with: the default choice  
(python) ensured that some scripts would fail. Now all scripts succeed.

The problem as it relates to py-appscript is that py-appscript doesn't  
need WM access, but the OS promotes it anyway as a side-effect of  
calling certain Carbon APIs from within a .app bundle. The script  
ought to run as a regular *nix process, responding to standard *nix  
signals as needed, but the OS frustrates that. Annoying, but tweaking  
the Python.app bundle's LSBackgroundOnly/LSUIElement flags isn't a  
solution, it's a kludge - one that will take us back to the bad old  
days where some scripts automatically fail when run with 'python'.

The correct solution would be for Apple to make their APIs more  
selective about upgrading the process when it doesn't need to be, but  
I doubt it's something that's important to them so don't hold your  
breath. The alternative is for Python to provide a 'pythonb' (where  
'b' stands for 'background') alternative to the default 'python'  
interpreter that scripts can use when they know they don't need WM  
access. And if you eventually want to get to the point of having only  
a single 'python' interpreter, you could start pushing the Tk, wx,  
etc. folks to add their own code for upgrading the process at startup,  
and then do away with the .app bundle in a few more years once you can  
be confident that you aren't going to break any scripts by doing so.

...

The other thing I will suggest is that somebody figures out a patch  
for appscript that replaces the current Process Manager calls with  
calls of equivalent functionality that do not cause the OS to upgrade  
the process. I _do_not_ have time to work on this problem myself (I am  
up to my ears in RL commitments), but I'll be delighted to incorporate  
any contributed patch that I'm satisfied won't break any of  
appscript's existing behaviour. It must be doable: Leopard's Scripting  
Bridge manages to avoid triggering the upgrade process, and I'm  
assuming (though have not checked) that it also targets processes by  
pid.

Regards,

has
-- 
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net