tp_compare and tp_richcompare NULL before deciding to do a quickie
based on the object address.  (Tim Peters discovered this.)

I found where rich comparison of unequal recursive objects gave
unintuituve results.  In a discussion with Tim, where we discovered
that our intuition on when a<=b should be true was failing, we decided
to outlaw ordering comparisons on recursive objects.  (Once we have
fixed our intuition and designed a matching algorithm that's practical
and reasonable to implement, we can allow such orderings again.)

- Refactored the recursive-object comparison framework; more is now
  done in the support routines so less needs to be done in the calling
  routines (even at the expense of slowing it down a bit -- this
  should normally never be invoked, it's mostly just there to avoid
  blowing up the interpreter).

- Changed the framework so that the comparison operator used is also
  stored.  (The dictionary now stores triples (v, w, op) instead of
  pairs (v, w).)

- Changed the nesting limit to a more reasonable small 20; this only
  slows down comparisons of very deeply nested objects (unlikely to
  occur in practice), while speeding up comparisons of recursive
  objects (previously, this would first waste time and space on 500
  nested comparisons before it would start detecting recursion).

- Changed rich comparisons for recursive objects to raise a ValueError
  exception when recursion is detected for ordering oprators (<, <=,
  >, >=).

Unrelated change:

- Moved PyObject_Unicode() to just under PyObject_Str(), where it
  belongs.  MAL's patch must've inserted in a random spot between two
  functions in the file -- between two helpers for rich comparison...

for comparisons that outlaws requets for ordering on recursive data
structures, remove the tests for ordering recursive data structures.

    "platform", running the Python binary to create it, and then
    using it to set PYTHONPATH.

   wraps to 80chars, and adds some really hacky setting of compiler
   options when CC and LDSHARED are given on the make command line.
   (The Distutils should probably provide a utility function to
    automatically handle a number of common environment variables)

Check additional include directories for SSL
Don't build modules that are linked into the Python binary statically
Factored out the detection of Tkinter out into a method, since it's
    the most complicated module to set up
Simplify the logic for detecting Tkinter

   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.