iterable object.  I'm not sure how that got overlooked before!

Got rid of the internal _PySequence_IterContains, introduced a new
internal _PySequence_IterSearch, and rewrote all the iteration-based
"count of", "index of", and "is the object in it or not?" routines to
just call the new function.  I suppose it's slower this way, but the
code duplication was getting depressing.

saving instead a traceback string, but test_support's run_unittest was
still peeking into unittest internals and trying to pick apart unittest's
errors and failures vectors as if they contained exc_info() tuples instead
of strings.
Whatever, when a unittest-based test failed, test_support blew up.  I'm
not sure this is the right way to fix it; it simply gets me unstuck.

the base classes is not a classic class, and its class (the metaclass)
is callable, call the metaclass to do the deed.

One effect of this is that, when mixing classic and new-style classes
amongst the bases of a class, it doesn't matter whether the first base
class is a classic class or not: you will always get the error
"TypeError: metatype conflict among bases".  (Formerly, with a classic
class first, you'd get "TypeError: PyClass_New: base must be a class".)

Another effect is that multiple inheritance from ExtensionClass.Base,
with a classic class as the first class, transfers control to the
ExtensionClass.Base class.  This is what we need for SF #443239 (and
also for running Zope under 2.2a4, before ExtensionClass is replaced).

corresponding "getitem" operation (sq_item or mp_subscript) is
implemented.  I realize that "sequence-ness" and "mapping-ness" are
poorly defined (and the tests may still be wrong for user-defined
instances, which always have both slots filled), but I believe that a
sequence that doesn't support its getitem operation should not be
considered a sequence.  All other operations are optional though.

For example, the ZODB BTree tests crashed because PySequence_Check()
returned true for a dictionary!  (In 2.2, the dictionary type has a
tp_as_sequence pointer, but the only field filled is sq_contains, so
you can write "if key in dict".)  With this fix, all standalone ZODB
tests succeed.

a->tp_mro.  If a doesn't have class, it's considered a subclass only
of itself or of 'object'.

This one fix is enough to prevent the ExtensionClass test suite from
dumping core, but that doesn't say much (it's a rather small test
suite).  Also note that for ExtensionClass-defined types, a different
subclass test may be needed.  But I haven't checked whether
PyType_IsSubtype() is actually used in situations where this matters
-- probably it doesn't, since we also don't check for classic classes.

Also remove mappings that are not registered with IANA, and not extensions.

the module in multiple threads with a global lock.

out of the box on OSX 10.1. Untested by me (except for not having adverse
effects on 10.0.4) but it looks good, for now. Eventually we should not
trigger on the darwin version but test for something, but until I have
the time to install 10.1 myself I have no clue what to test on.

It would be nice if this got in to the 2.2a3 distribution.

If after calculating sys.path we do not have sys.prefix set, we loop over all path entries checking if one can point to our home directory.

enough, but may have side-effects because it preallocates a single
codeop.Compiler() to compile all statements the user enters.

Just: please review and retract/modify if necessary.

com_factor():  when a unary minus is attached to a float or imaginary zero,
don't optimize the UNARY_MINUS opcode away:  the const dict can't
distinguish between +0.0 and -0.0, so ended up treating both like the
first one added to it.  Optimizing UNARY_PLUS away isn't a problem.

(BTW, I already uploaded the 2.2a3 Windows installer, and this isn't
important enough to delay the release.)

branch (if it ever gets to the typo, the test is failing anyway).

capabilities of the Pentium FPU, so what should have been (and were on
Windows) exact results got fuzzy.  Then it turns out test_support.fcmp()
isn't tolerant of tiny errors when *one* of the comparands is 0, but
test_complex's old check_close_real() is.  Rather than fix gcc <wink>,
easier to revert this test and revisit after the release.

existed when I wrote this test.

has more bits than the numerator than can be counted in a C int (yes,
that's unlikely, and no, I'm not adding a test case with a 2 gigabit
long).

This closes SF bug #459256.

(Steve, can you add this to the PyUnit repository as well?)

This closes SF bug #458785.

Fixes bug reported as SF bug #453728.

less hostile to newbie use at the interactive prompt.
This is in response to SF bug #458654.

Add refcount information for other recently documented APIs.

statement that this is a proof-of-concept meant for people to
experiment with, nothing more.

in Python.