Closes SF bug #579991.

The test of httplib makes it difficult to maintain httplib.  There are
two many idioms that pyclbr doesn't seem to understand, and I don't
understand how to update these tests to make them work.

Also remove commented out test of urllib2.

Client code could create responses explicitly.

more spaces only crashed pdb.

While I was at it, cleaned up some style nits (spaces between function
and parenthesis, and redundant parentheses in if statement).

calling Python was installed was so complicated, so I simplified it.

This should get the snake-farm's build scripts working again.

ULONG_MAX -- removed; std C requires it in limits.h
LONGLONG_MAX -- removed; never used
ULONGLONGMAX -- removed; never used

PyImport_ImportModule() is not guaranteed to return a module object.
When another type of object was returned, the PyModule_GetDict() call
return NULL and the subsequent GetItem() seg faulted.

Bug fix candidate.

arg tuple.  This was suggested on c.l.py but afraid I can't find the msg
again for proper attribution.  For

    list.sort(cmp)

where list is a list of random ints, and cmp is __builtin__.cmp, this
yields an overall 50-60% speedup on my Win2K box.  Of course this is a
best case, because the overhead of calling cmp relative to the cost of
actually comparing two ints is at an extreme.  Nevertheless it's huge
bang for the buck.  An additionak 20-30% can be bought by making the arg
tuple an immortal static (avoiding all but "the first" PyTuple_New), but
that's tricky to make correct since docompare needs to be reentrant.  So
this picks the cherry and leaves the pits for Fred <wink>.

Note that this makes no difference to the

    list.sort()

case; an arg tuple gets built only if the user specifies an explicit
sort function.

Bump version number.

type with get_type().

Bug fix candiadte.

Expand the "Other Language Changes" section
Rewrite various passages.

takes much longer to run in the context of the test suite than when run in
isolation.  That's because it forces a large number of full collections,
which take time proportional to the total number of gc'ed objects in the
whole system.

But since the dangerous implementation trickery that caused this test to
fail in 2.0, 2.1 and 2.2 doesn't exist in 2.3 anymore (the trashcan
mechanism stopped doing evil things when the possibility for compiling
without cyclic gc was taken away), such an expensive test is no longer
justified.  This checkin leaves the test intact, but fiddles the
constants to reduce the runtime by about a factor of 5.

Also, simplify some ref counting for other optional arguments.

immortal object here as a leak.  Made the object mortal again at the end.

debug-build failure when an instance of a new-style class is resurrected
by a __del__ method -- we simply never had any code that tried this.

This is already fixed in 2.3 CVS.  In 2.2.1, it blows up via

    Fatal Python error: GC object already in linked list

I'll fix it in 2.2.1 CVS next.

helper macros to something saner, and used them appropriately in other
files too, to reduce #ifdef blocks.

classobject.c, instance_dealloc():  One of my worst Python Memories is
trying to fix this routine a few years ago when COUNT_ALLOCS was defined
but Py_TRACE_REFS wasn't.  The special-build code here is way too
complicated.  Now it's much simpler.  Difference:  in a Py_TRACE_REFS
build, the instance is no longer in the doubly-linked list of live
objects while its __del__ method is executing, and that may be visible
via sys.getobjects() called from a __del__ method.  Tough -- the object
is presumed dead while its __del__ is executing anyway, and not calling
_Py_NewReference() at the start allows enormous code simplification.

typeobject.c, call_finalizer():  The special-build instance_dealloc()
pain apparently spread to here too via cut-'n-paste, and this is much
simpler now too.  In addition, I didn't understand why this routine
was calling _PyObject_GC_TRACK() after a resurrection, since there's no
plausible way _PyObject_GC_UNTRACK() could have been called on the
object by this point.  I suspect it was left over from pasting the
instance_delloc() code.  Instead asserted that the object is still
tracked.  Caution:  I suspect we don't have a test that actually
exercises the subtype_dealloc() __del__-resurrected-me code.

2. Consolidate Undo code in EditorWindow.EditorWindow
3. Remove Formatting and Run menus from PyShell

reconstruct that info.
Filled out some sketchy explanations of pragmatics.