Don't use our own temp name creation (dbm).
Should be backported to 2.5.

Create a real zip iterator object; not using itertools.izip
(Brian Holmes).

import MAGIC number.

``python -m compileall -f`` is really handy for finding Python files that use
invalid syntax.

Still need to remove traces of the UNARY_CONVERT opcode.

optimization for it.

SyntaxError.

This is probably not the proper solution to this failing test, but removing the
test itself causes 19 other tests to fail for some odd reason because doctest
doesn't expect a complete traceback (or something; rather odd problem for just
removing a single test).

auto-generates this file will need to get fixed.

'<>'.

use __eq__ instead of __cmp__.  The other change is unexplained:
with a random hash code as before, it would run forever; with a constant
hash code, it fails quickly.

This found a refcount bug in dict_equal() -- I wonder if that bug is
also present in 2.5...

I mea, *really* equal -- for now, the implementation just imports
itertools. :-)
The only other changes necessary were various unit tests that were
assuming zip() returns a real list.  No "real" code made this assumption.

This essentially meant fixing one case where a list of custom objects
was being sorted, and fixing one genuine bug where a method call was
missing parentheses.

The special-casing of other objects with a timetuple attribute is gone.
Let's hope Tim agrees.

This makes test_codeop and test_marshal pass.

Opportunistically also fixed one or two places where '<> None' should be
'is not None' and where 'type(x) <> y' should be 'not isinstance(x, y)'.

in the stdlib and changed each of them to use "open" instead.  At this
time there are no other known occurrences that can be safely changed (in
Lib and all subdirectories thereof).

*ordering* between objects; there is only a default equality test
(defined by an object being equal to itself only).  Read the comment
in object.c.  The current implementation never uses a three-way
comparison to compute a rich comparison, but it does use a rich
comparison to compute a three-way comparison.  I'm not quite done
ripping out all the calls to PyObject_Compare/Cmp, or replacing
tp_compare implementations with tp_richcompare implementations;
but much of that has happened (to make most unit tests pass).

The following tests still fail, because I need help deciding
or understanding:

test_codeop -- depends on comparing code objects
test_datetime -- need Tim Peters' opinion
test_marshal -- depends on comparing code objects
test_mutants -- need help understanding it

The problem with test_codeop and test_marshal is this: these tests
compare two different code objects and expect them to be equal.
Is that still a feature we'd like to support?  I've temporarily
removed the comparison and hash code from code objects, so they
use the default (equality by pointer only) comparison.

For the other two tests, run them to see for yourself.
(There may be more failing test with "-u all".)

A general problem with getting lots of these tests to pass is
the reality that for object types that have a natural total ordering,
implementing __cmp__ is much more convenient than implementing
__eq__, __ne__, __lt__, and so on.  Should we go back to allowing
__cmp__ to provide a total ordering?  Should we provide some other
way to implement rich comparison with a single method override?
Alex proposed a __key__() method; I've considered a __richcmp__()
method.  Or perhaps __cmp__() just shouldn't be killed off...

being before 'start') would actually assign to b[0:0] (or whatever 'stop'
was)

to relative import issues.  Any volunteers?

attempts at backwards compatibility which can't work anyway on Py3k (and aren't
needed for Python 2.5 and later).