Update the patch and bug counts

in one place.

"module parameters", and used in the Windows test (which crashed
because size was undefined -- sigh).

by bbrox@bbrox.org / lionel.ulmer@free.fr.

This adds a configure check and if all goes well turns on the
PTHREAD_SCOPE_SYSTEM thread attribute for new threads.

This should remove the need to add tiny sleeps at the start of threads
to allow other threads to be scheduled.

If on Windows, we require the 'largefile' resource.

If not on Windows, we use a test that actually writes a byte beyond
the 2BG limit -- seeking alone is not sufficient, since on some
systems (e.g. Linux with glibc 2.2) the sytem call interface supports
large seek offsets but not all filesystem implementations do.

Note that on Windows, we do not use the write test: on Win2K, that
test can take a minute trying to zero all those blocks on disk, and on
Windows our code always supports large seek offsets (but again, not
all filesystems do).  This may mean that on Win95, or on certain other
backward filesystems, test_largefile will *fail*.

Add removal of 3-arg pow() for floats
Rewrite introduction a bit

Reported by Fredrik Lundh on python-dev.

The conversimple() code that handles Unicode arguments and converts
them to the default encoding now calls converterr() with the original
Unicode argument instead of the NULL returned by the failed encoding
attempt.

support on Linux (and Solaris, I expect) for real.
The necessary symbols are defined once and for all,
under the assumption that they won't harm elsewhere.

horridly inefficient hack in regrtest's Compare class, but it's about as
clean as can be:  regrtest has to set up the Compare instance before
importing a test module, and by the time the module *is* imported it's too
late to change that decision.  The good news is that the more tests we
convert to unittest and doctest, the less the inefficiency here matters.
Even now there are few tests with large expected-output files (the new
cost here is a Python-level call per .write() when there's an expected-
output file).

type reprs, to accomodate the way Jack runs tests on the Mac.

selftest now works.

stored in the CVS repository). It can either decode resource/data forks
in the standard Mac way or decode only the resource fork but store
the result in the data fork (the MacOSX preferred way). Finder info
and all other stuff is ignored.

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.)