available as "oldsharedmods" and "oldsharedinstall".  You'll need
   to get a copy of the full Setup.dist out of the CVS for them to
   actually do much.

these fall back to __cmp__.

Added Copyright GvR.

- Changed description of rich comparisons to emphasize that < and >
  (etc.) are each other's reflection.  Also use this word in the note
  about the demise of __rcmp__.

exceptions when compared using <, <=, > or >=.

NOTE: This is a tentative change: this means that cmp() involving
complex numbers will raise an exception when the numbers differ, and
that in turn means that e.g. dictionaries and certain other compounds
(e.g. UserLists) containing complex numbers can't be compared either.
So we'll have to decide whether this is acceptable.  The alpha test
cycle is a good time to keep an eye on this!

- In count(), remove(), index(): call RichCompare(Py_EQ).

- Get rid of array_compare(), in favor of new array_richcompare() (a
  near clone of list_compare()).

- Aligned items in array_methods initializer and comments for type
  struct initializer.

- Folded a few long lines.

- Use PyObject_RichCompareBool() when comparing keys; this makes the
  error handling cleaner.

- There were two implementations for dictionary comparison, an old one
  (#ifdef'ed out) and a new one.  Got rid of the old one, which was
  abandoned years ago.

- In the characterize() function, part of dictionary comparison, use
  PyObject_RichCompareBool() to compare keys and values instead.  But
  continue to use PyObject_Compare() for comparing the final
  (deciding) elements.

- Align the comments in the type struct initializer.

Note: I don't implement rich comparison for dictionaries -- there
doesn't seem to be much to be gained.  (The existing comparison
already decides that shorter dicts are always smaller than longer
dicts.)

- tuplecontains(): call RichCompare(Py_EQ).

- Get rid of tuplecompare(), in favor of new tuplerichcompare() (a
  clone of list_compare()).

- Aligned the comments for large struct initializers.

earlier coercion changes, not by rich comparisons.  When a coercion
function returns 1 (meaning it cannot do it), it should not INCREF the
arguments.  When no __coerce__() method was found, instance_coerce()
originally returned 0, pretending it did it.  Neil changed the return
value to 1, more accurately reflecting that it didn't do anything, but
forgot to take out the two INCREF calls.

subproject is gone, replaced by the new pythoncore subproject.

    and remove support for it from setup.py

- sort's docompare() calls RichCompare(Py_LT).

- list_contains(), list_index(), listcount(), listremove() call
  RichCompare(Py_EQ).

- Get rid of list_compare(), in favor of new list_richcompare().  The
  latter does some nice shortcuts, like when == or != is requested, it
  first compares the lengths for trivial accept/reject.  Then it goes
  over the items until it finds an index where the items differe; then
  it does more shortcut magic to minimize the number of additional
  comparisons.

- Aligned the comments for large struct initializers.

- get version number from sys.version_info

'verify' iff it's used by a test module...

didn't import it.  Also got rid of some inconsistent spaces inside
parentheses in test_gzip.py.

- Use the compare nesting level and in-progress dictionary properly in
  PyObject_RichCompare().

- Change the in-progress code to use static variables instead of
  globals (both the nesting level and the key for the thread dict were
  globals but have no reason to be globals; the key can even be a
  function-static variable in get_inprogress_dict()).

- Rewrote try_rich_to_3way_compare() to benefit from the similarity of
  the three cases, making it table-driven.

- In try_rich_to_3way_compare(), test for EQ before LT and GT.  This
  turns out essential when comparing recursive UserList instances;
  with the old code, these would recurse into rich comparison three
  times for each nesting level up to NESTING_LIMIT/2, making the total
  number of calls in the order of 3**(NESTING_LIMIT/2)!

NOTE: I'm not 100% comfortable with this.  It works for the standard
test suite (which compares a few trivial recursive data structures
only), but I'm not sure that the in-progress dictionary is used
properly by the rich comparison code.  Jeremy suggested that maybe the
operation should be included in the dict.  Currently I presume that
objects in the dict are equal unless proven otherwise, and I set the
outcome for the rich comparison accordingly: true for operators EQ,
LE, GE, and false for the other three.  But Jeremy seems to think that
there may be counter-examples where this doesn't do the right thing.

   Check for the two possible headers for Expat, expat.h and xmlparse.h,
   and only compile the pyexpat module if one of them is found.

   oversight in using self.compiler.library_dirs)

and replaces them with a new API verify(). As a result the regression
suite will also perform its tests in optimization mode.

Written by Marc-Andre Lemburg. Copyright assigned to Guido van Rossum.

Not that Jack doesn't deserve them, but saying it so often cheapens the
sentiment.