Changed version numbers and copyright.

    the compiler

    Walter Doerwald provided a patch, which I've modified in two ways:

1) (Uncontroversial) Removed code to make module work in earlier versions of
   Python without the unicode() built-in

2) (Poss. controversial) Instead of making string.zfill take the repr()
   of non-string objects, take the str().

Should a warning be added to this branch of the code so that the automatic
str() can be deprecated?

2.2.2 bugfix candidate, assuming the repr()->str() change is deemed OK.

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!