and the selection can be looked up, and so can the Carbon manual. From the
help menu you can also get to the online documentation, the Python website
and the MacPython page.
Untested in MacPython-OS9.
HTML tarball and use it to create a documentation tree readable and
searchable with Apple Help Viewer. The documentation also shows up in
Project Builder (if you add Python.framework to your project).
in Python.app, and refer to it in Info.plist. This makes Apple Help
Viewer recognize the Python documentation.
- Changed the externally visible name of Python.app to "Python" (was PythonW).
This is a silly workaround for a rather serious bug in MacOSX: if you take
a long filename and convert it to an FSSpec the fsspec gets a magic
cooky (containing a #, indeed). If you then massage the extension of this
fsspec and convert back to a pathname you may end up referring to the
same file. This could destroy your sourcefile. The problem only occcurs
in MacPython-OS9, not MacPython-OSX (I think).
Closes bug #505562.
the framework, the MacOSX apps and the unix tools.
Most of the hard work is done by Mac/OSX/Makefile.
Also, it should now be possible to install in a different directory,
such as /tmp/dist/Library/Frameworks, for building binary installers.
The fink crowd wanted this.
in stead of prepending it, which messes up "import * from".
- A few ascii()s added again.
- Changed the getbaseclasses a little, but it still isn't perfect.
This patch makes inheritance for OSA classes work. The implementation is a
bit convoluted, but I don't immedeately see a simpler way of doing it.
I added calls to ascii() everywhere we output strings that may contain
non-ascii characters (Python has gotten very picky since the encoding
patch:-).
I also removed Donovan's different way of opening resource files: I don't
seem to need it.
at compile time: use PBGetCatInfoSync() to get FInfo data in stead of
GetFInfo. The latter doesn't work for folders. The former does, at
least on OSX, and insofar the info makes sense for a folder.
where it was: it is really a configuration file, not a normal module.
By moving it into Mac/Lib we can now also store the location of bgen
itself in there, which is needed because bgen isn't installed.
Builder carbon NIB files from Python. As-is, I may need to twiddle a few
things as he donated this long ago.
Donovan is now one of the four people in the world who know how to drive
bgen!
argv emulation (i.e. if the end user drops files and folders on the
applets these will show up in sys.argv) BuildApplet will add the required
code to the applet bundle, in __rawmain__.pyc.
This code is compiled from appletrawmain.py, it creates sys.argv, cleans
up most of the mess and executes either __main__.py or __main__.pyc.
actual script to run in case we are running from an applet. If we are indeed
running an applet we skip the normal option processing leaving it all to the
applet code.
This allows us to get use the normal python binary in the Python.app bundle,
giving us all the normal command line options through PythonLauncher while
still allowing Python.app to be used as the template for building applets.
Consequently, pythonforbundle is gone, and Mac/Python/macmain.c isn't used
on OSX anymore.
doubleclicks a .py, .pyw or .pyc file. It runs the file by invoking the
relevant interpreter (either the command line Python in a terminal window
or a Python.app for GUI-based scripts). Interpreter to use and the options
to pass are settable through preferences.
If PythonLauncher wasn't running it does its thing for one script and exits.
If it was manually started before a dialog is presented where the user
can set the options to use, etc.
To be done:
- option-drag/doubleclick should always open the interactive dialog
- Terminal-window isn't done yet
- Should be reimplemented in Python, but pyobjc isn't part of the core.
- Various menu entries should be disabled.
The staticforward define was needed to support certain broken C
compilers (notably SCO ODT 3.0, perhaps early AIX as well) botched the
static keyword when it was used with a forward declaration of a static
initialized structure. Standard C allows the forward declaration with
static, and we've decided to stop catering to broken C compilers. (In
fact, we expect that the compilers are all fixed eight years later.)
I'm leaving staticforward and statichere defined in object.h as
static. This is only for backwards compatibility with C extensions
that might still use it.
XXX I haven't updated the documentation.
OSX framework build process. Things fixed/modified:
- the filesystem case-sensitivity test now works for builds outside
the source directory
- various other fixes for building outside the source directory
- python.app now has a target in the main Makefile
- WASTE and AquaTk are found more automatically
Jack Jansen
Jeremy Hylton
Just van Rossum