Apple-installed Python 2.2 from /usr/bin as it's underlying engine.
All the MacPython stuff is installed into /Applications/MacPython-OSX,
and .pth files and other magic are used to tie everything together.
So far only the raw windowing interpreter and BuildApplet work.
IDLE (it was a fatal error before)
- Shuffled a few things around to facilitate the experimental building
of MacPython for Jaguar's pre-installed python.
dialogs are now stored in Mac/Lib, and loaded on demand through macresource.
Not only does this simplify a MacPython based on Apple's Python, but
it also makes Mac error codes come out symbolically when running command
line python (if you have Mac/Lib in your path).
The resource files are copied from Mac/Resources. The old ones will disappear
after the OS9 build procedure has been adjusted.
if SetDates() in touched() returns an error ignore it: the user may not have
permission to change the parent folder. This is a non-serious problem,
the only function of touched() is to speed up the finder seeing the
change.
(or don't always?) show up with missed(). I think this is a bug in
Jaguar, but as it is a potential dangerous problem (the OSA event has
failed, but the Python code isn't told about this and happily continues)
this is a quick workaround.
Bugfix candidate, I'll add it to 2.2.2 as a last second fix.
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
These built-in functions are replaced by their (now callable) type:
slice()
buffer()
and these types can also be called (but have no built-in named
function named after them)
classobj (type name used to be "class")
code
function
instance
instancemethod (type name used to be "instance method")
The module "new" has been replaced with a small backward compatibility
placeholder in Python.
A large portion of the patch simply removes the new module from
various platform-specific build recipes. The following binary Mac
project files still have references to it:
Mac/Build/PythonCore.mcp
Mac/Build/PythonStandSmall.mcp
Mac/Build/PythonStandalone.mcp
[I've tweaked the code layout and the doc strings here and there, and
added a comment to types.py about StringTypes vs. basestring. --Guido]
verbose output to the console, etc.
- Allow Cocoa applets to be built with BuildApplet.
No full testing has been done yet to ensure OS9 operation hasn't suffered.
