[Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
hengist.podd at virgin.net
Tue Feb 3 16:53:27 CET 2009
Bill Janssen wrote:
> Chris, if you followed the thread, you'll know that what's happening
> 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
> 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
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
Control AppleScriptable applications from Python, Ruby and ObjC:
More information about the Pythonmac-SIG