for SocketServer.py (inherited by TCPServer)

Luke wrote:

  The socketserver code, with a little bit of tweaking, can be made
  sufficiently general to service "requests" of any kind, not just by sockets.
  The BaseServer class was created, for example, to poll a table in a MYSQL
  database every 2 seconds. each entry in the table can be allocated a
  Handler which deals with the entry.

  With this patch, using BaseServer and ThreadedServer classes, the creation
  of the server that reads and handles MySQL table entries instead of a
  socket was utterly trivial: about 50 lines of python code.

  You may consider this code to be utterly useless [why would anyone else
  want to do anything like this???] - you are entitled to your opinion. if you
  think so, then think of this: have you considered how to cleanly add SSL to
  the TCPSocketServer? What about using shared memory as the
  communications mechanism for a server, instead of sockets? What about
  communication using files?

  The SocketServer code is extremely good every useful. it's just that as it
  stands, it is tied to sockets, which is not as useful.

I heartily approve of this idea.

libraries.

(I have no way to test this, I just trust Donn.)

Support building this as a DLL under Cygwin.

Minor startup speedup: avoid a call to strspn().

not __hash__ raises TypeError.

__cmp__ and __eq__ absent before deciding to do a quickie
based on the object address.  (Tim Peters discovered this.)

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.