tuple(i) repaired to return a true tuple when i is an instance of a
tuple subclass.
Added PyTuple_CheckExact macro.
PySequence_Tuple():  if a tuple-like object isn't exactly a tuple, it's
not safe to return the object as-is -- make a new tuple of it instead.

parameter for the return string (as unix pathnames are not limited
by the 255 char pstring limit).
Implemented the function for MachO-Python, where it returns unix pathnames.

xmllib (on 2.0 and later)

Repair float constructor to return a true float when passed a subclass
instance.  New PyFloat_CheckExact macro.

Given an immutable type M, and an instance I of a subclass of M, the
constructor call M(I) was just returning I as-is; but it should return a
new instance of M.  This fixes it for M in {int, long}.  Strings, floats
and tuples remain to be done.
Added new macros PyInt_CheckExact and PyLong_CheckExact, to more easily
distinguish between "is" and "is a" (i.e., only an int passes
PyInt_CheckExact, while any sublass of int passes PyInt_Check).
Added private API function _PyLong_Copy.

Subtlety on Windows: if we change test_largefile.py to use a file
> 4GB, it still fails.  A debug session suggests this is because
fseek(fp, 0, 2) refuses to seek to the end of the file when the file
is > 4GB, because it uses the SetFilePointer() in 32-bit mode.

But it only fails when we seek relative to the end of the file,
because in the other seek modes only calls to fgetpos() and fsetpos()
are made, which use Get/SetFilePointer() in 64-bit mode.  Solution:
#ifdef MS_WInDOWS, replace the call to fseek(fp, ...) with a call to
_lseeki64(fileno(fp), ...).  Make sure to call fflush(fp) first.

(XXX Could also replace the entire branch with a call to _lseeki64().
Would that be more efficient?  Certainly less generated code.)

(XXX This needs more testing.  I can't actually test that it works for
files >4GB on my Win98 machine, because the filesystem here won't let
me create files >=4GB at all.  Tim should test this on his Win2K
machine.)

xmllib unless needed), merged docstring patches, added overridable
Transport.getparser to simplify plugging in different parsers.

  - use PyModule_Check() instead of PyObject_TypeCheck(), now we can.
  - don't assert that the __dict__ gotten out of a module is always
    a dictionary; check its type, and raise an exception if it's not.

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