priority, for safety reasons.

datafork-based resource file before trying to decode it as AppleSingle.

python.
Removed debug output.

/usr/local/bin (referring to the framework-based interpreter and Python.app).

Added target symlinkmacsubtree to aid in debugging.

because of similarity to the same program on Windows.

of trash objects.  Use the gc_prev pointer instead.

type implementation.

include them using \verbatiminput.  This has the advantage that pages
can still break at reasonable places, and examples that go longer than
a page won't get cut off.

Make a few small markup adjustments for consistency.

Explain that PyObject_New() is not a C function but a polymorphic
beast that returns a pointer to the type that's passed as the first
arg.

Explain why type objects use the PyObject_VAR_HEAD.

It appears that getcomments() can get called for classes defined in
C.  Since these don't have source code, it can't do anything useful.
A function buried many levels deep was raising a TypeError that was
not caught.

Who knows why this broke...

as a verbatim environment.  (The HTML version is already fine.)

mentioned in the library reference manual

Bugfix candidate.

under 2.0, 2.1 and 2.2.

Bugfix candidate.

but at least the content is there.

The fix makes it possible to call PyObject_GC_UnTrack() more than once
on the same object, and then move the PyObject_GC_UnTrack() call to
*before* the trashcan code is invoked.

BUGFIX CANDIDATE!

SF bug 535905 (Evil Trashcan and GC interaction).

The SETLOCAL() macro should not DECREF the local variable in-place and
then store the new value; it should copy the old value to a temporary
value, then store the new value, and then DECREF the temporary value.
This is because it is possible that during the DECREF the frame is
accessed by other code (e.g. a __del__ method or gc.collect()) and the
variable would be pointing to already-freed memory.

BUGFIX CANDIDATE!

2.2.2 candidate.

fast, and just cluttered the code.  Get rid of it for now.  If a compelling
case can be made for it, easy to restore it later.

descriptor, as used for the tp_methods slot of a type.  These new flag
bits are both optional, and mutually exclusive.  Most methods will not
use either.  These flags are used to create special method types which
exist in the same namespace as normal methods without having to use
tedious construction code to insert the new special method objects in
the type's tp_dict after PyType_Ready() has been called.

If METH_CLASS is specified, the method will represent a class method
like that returned by the classmethod() built-in.

If METH_STATIC is specified, the method will represent a static method
like that returned by the staticmethod() built-in.

These flags may not be used in the PyMethodDef table for modules since
these special method types are not meaningful in that case; a
ValueError will be raised if these flags are found in that context.

2.2.2 candidate.