[Pythonmac-SIG] Extensions for static versus frame

[Jack Jansen]

On dinsdag, juli 16, 2002, at 07:43 , Chris Barker wrote:
[lots of detail and explanation omitted]
> I am primarily a Linux user, and I don't see much advantage at all to
> the second approach.

Ok, thanks, that was about my own line of reasoning too!

> On another issue, but related to what the standard install should look
> like:
>> If you try to run Python.app twice by
>> double-clicking on a second .py script while the first one is still
>> running it doesn't work, but I woulnd't expect a bus error (I would
>> expect nothing to happen).
>
> This needs to be solved. Except for command line use, Python is not an
> application. It is a virtual machine or runtime environment, and should
> be invisible to users running multiple python programs at once. Is the
> above mentioned "Python Launcher.app" the solution to this?

yes, it is. Just and myself had a session of heavy MachoPython 
design last week, and here's what we've come up with. please 
comment.

The thing that we now call /Applications/Python.app will become 
hidden: it will move into the Python.framework somewhere. It 
will also *not* advertise (in its .plist file) itself as capable 
of running Python scripts. It will be changed a little, mainly 
replacing macmain.c by the standard Modules/main.c with a little 
mod to allow it to look for __rawmain__.py or .pyc, so it can 
still be used for building applets. The tricky AppleEvent code 
to create sys.argv on startup will be re-implemented in Python, 
and applets that need it will get it in their __rawmain__.py 
(and that's the only place it will be used).

There will be a new program /Applications/Python Launcher.app, 
modelled after Java's Applet Launcher (hmm, maybe it should go 
into Utilities?). It will understand two file types: ".py" and 
".pyw". If a script.py is doubleclicked it will by default open 
a terminal window and run 
"/Library/Frameworks/Python.framework/Versions/Current/bin/python 
script.py" in it. If a script.pyw is doubleclicked it will run 
(without a terminal window)  
"...../Python.app/Contents/MacOS/python script.pyw". This 
.py/.pyw distinction, and the behaviour, is modelled after the 
way things work on Windows.

Python Launcher will get a couple of bells and whistles 
(modelled after how Stuffit Expander works, of all tools:-): if 
you option-drag or option-double-click a script you get a chance 
to add the verbose flag and other flags to Python, or pick a 
diffferent interpreter. Also, if you manually run the launcher 
you get access to it's preferences dialog, where you can set the 
defaults for these (or restore the "factory defaults"), 
separately for .py and .pyw scripts.

I'm pretty happy with this solution, as it is pretty mac-like 
(for instance, the Get Info box can be used to select whether 
the IDE or the launcher should open a document by default, and 
use drag and drop if they want the other one) and it's also 
pretty familiar to people coming from Windows (.py -> you get a 
console for your I/O, .pyw -> no ugly consoles if you want to do 
your own UI, be it with wxWindows, Tkinter, Carbon or Cocoa).

Please feel free to rain on my parade and tell us what we 
missed, where we seriously messed up the design or why this idea 
will never fly:-)
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- 
Emma Goldman -