[Pythonmac-SIG] A MachO Python application in 2.2a3 - please try it!

[Jack Jansen]

Folks,
in Python 2.2a3, which went out earlier today, there is a feature that
I would like people to play with. Note that this refers to
unix-Python, MacPython 2.2a3 will come soon (monday at the latest, is
my guess).

Anyway, if you build Python as a framework and install that you can
create a "real" Python application with a Makefile that is in
Mac/OSX. You can drop Python scripts on this application and they'll
run in a full windowing environment, so you should be able to open
dialogs, etc.

All this was quickly hacked together by using the MacPython main.c and
getargv.c (one evening got it working!) so it's probably still a
little rough around the edges. For one thing I think it loses argv[0],
the program name, at the moment. Still, I think this may be a good
starting point to experiment with Carbon development on OSX
MachO-Python. And even though I know next to nothing about the ObjC
module and Cocoa I have the hope that this could also kick that back
into life, because now your script gets run as true application,
appearing in the dock, etc.

Here is some of the things that I had in mind doing, but won't get
around until I'm back from holidays (early october), so feel free to
beat me to it and/or implement something better.

1. I think we can do applets real easy. If the main program can get
its bundle directory it can check for a file Resources/__main__.py or
.pyc and if that exists it can execute that script. Presto, applets
are there!

2. It could also look for Resources/__rawmain__.py or pyc, and if that
exists also execute that script, *but skipping it's normal argv
emulation*. This would mean that when the script gets control the
appleevent that started it would still be sitting in the queue waiting
for you, similar to "don't do argc processing" in MacPython applets. I
think this may also be needed for Cocoa apps (but I'm not sure).

3. The .rsrc files in the unix distribution are not really resource
files, they're AppleSingle encoded resource files. My plan was to
leave this so, so they can survive tar transmission. The idea is that
there's going to be an AppleSingle decoder, and that if the new
macresource module (which is now used by all the standard modules that
used to simply open a .rsrc file) will detect that the xxxx.rsrc is an
AppleSingle file, and attempt to open xxxx.decoded.rsrc. If this file
doesn't exist (or is older that xxxx.rsrc) it would use the
AppleSingle module to unpack it.

4. Python.app currently misses all the standard resources (from
dialogs.rsrc and such). This means EasyDialogs won't work, and Python
may also use these resources internally. At some point the build
process should use AppleSingle to convert the .rsrc files to *data
fork* resources and put them in the right place in the application
bundle.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | ++++ see http://www.xs4all.nl/~tank/ ++++