k_mul():  This didn't allocate enough result space when one input had
more than twice as many bits as the other.  This was partly hidden by
that x_mul() didn't normalize its result.

The Karatsuba recurrence is pretty much hosed if the inputs aren't
roughly the same size.  If one has at least twice as many bits as the
other, we get a degenerate case where the "high half" of the smaller
input is 0.  Added a special case for that, for speed, but despite that
it helped, this can still be much slower than the "grade school" method.
It seems to take a really wild imbalance to trigger that; e.g., a
2**22-bit input times a 1000-bit input on my box runs about twice as slow
under k_mul than under x_mul.  This still needs to be addressed.

I'm also not sure that allocating a->ob_size + b->ob_size digits is
enough, given that this is computing k = (ah+al)*(bh+bl) instead of
k = (ah-al)*(bl-bh); i.e., it's certainly enough for the final result,
but it's vaguely possible that adding in the "artificially" large k may
overflow that temporarily.  If so, an assert will trigger in the debug
build, but we'll probably compute the right result anyway(!).

addition and subtraction.  Reworked the tail end of k_mul() to use them.
This saves oodles of one-shot longobject allocations (this is a triply-
recursive routine, so saving one allocation in the body saves 3**n
allocations at depth n; we actually save 2 allocations in the body).

new-style object creation/deallocation.

Moved all news about type/class unification and new-stype classes to a
separate section at the top.

SF 560379:  Karatsuba multiplication.
Lots of things were changed from that.  This needs a lot more testing,
for correctness and speed, the latter especially when bit lengths are
unbalanced.  For now, the Karatsuba code gets invoked if and only if
envar KARAT exists.

Add resolve() to handle looking up objects and names (fix SF bug 586931).
Add a nicer error message when given a filename that doesn't exist.

a lot of work, including I/O (e.g. to import warnings.py), which might
affect errno.

u'%c' will now raise a ValueError in case the argument is an
integer outside the valid range of Unicode code point ordinals.

Closes SF bug #593581.

currently return inconsistent results for ints and longs; in
particular: hex/oct/%u/%o/%x/%X of negative short ints, and x<<n that
either loses bits or changes sign.  (No warnings for repr() of a long,
though that will also change to lose the trailing 'L' eventually.)

This introduces some warnings in the test suite; I'll take care of
those later.

test_del(), test_del_newclass():  No need to use apply() in these.

in gc.garbage (so no need to loop looking for it -- it's there or it's
not).

the time it's called, test_saveall() made it look a leak, triggering
bogus warnings from regrtest's -l (findleaks) mode.

Reject characters outside the locale's encoding on input.

types.  This prevents nonsense like 2.__class__ = bool or
True.__class__ = int.

   This is friendlier for caches.

2. Cut MIN_GALLOP to 7, but added a per-sort min_gallop vrbl that adapts
   the "get into galloping mode" threshold higher when galloping isn't
   paying, and lower when it is.  There's no known case where this hurts.
   It's (of course) neutral for /sort, \sort and =sort.  It also happens
   to be neutral for !sort.  It cuts a tiny # of compares in 3sort and +sort.
   For *sort, it reduces the # of compares to better than what this used to
   do when MIN_GALLOP was hardcoded to 10 (it did about 0.1% more *sort
   compares before, but given how close we are to the limit, this is "a
   lot"!).  %sort used to do about 1.5% more compares, and ~sort about
   3.6% more.  Here are exact counts:

 i    *sort    3sort    +sort    %sort    ~sort    !sort
15   449235    33019    33016    51328   188720    65534  before
     448885    33016    33007    50426   182083    65534  after
      0.08%    0.01%    0.03%    1.79%    3.65%    0.00%  %ch from after

16   963714    65824    65809   103409   377634   131070
     962991    65821    65808   101667   364341   131070
      0.08%    0.00%    0.00%    1.71%    3.65%    0.00%

17  2059092   131413   131362   209130   755476   262142
    2057533   131410   131361   206193   728871   262142
      0.08%    0.00%    0.00%    1.42%    3.65%    0.00%

18  4380687   262440   262460   421998  1511174   524286
    4377402   262437   262459   416347  1457945   524286
      0.08%    0.00%    0.00%    1.36%    3.65%    0.00%

19  9285709   524581   524634   848590  3022584  1048574
    9278734   524580   524633   837947  2916107  1048574
      0.08%    0.00%    0.00%    1.27%    3.65%    0.00%

20 19621118  1048960  1048942  1715806  6045418  2097150
   19606028  1048958  1048941  1694896  5832445  2097150
      0.08%    0.00%    0.00%    1.23%    3.65%    0.00%

3. Added some key asserts I overlooked before.

4. Updated the doc file.

before %sort was introduced.  Redid them (the numbers change, but the
conclusions don't).  Also did the samplesort counts with the released
2.2.1, as they're slightly different under the last CVS 2.3 samplesort
(some higher, some lower -- CVS had been changed to stop doing the
special-case business on recursive samplesort calls).

on python.org.

directories clean where the packages are unpacked.  Each package now
contains a single directory, Python-Docs-<version>/, which contains the
files for that version of the documentation.

Closes SF feature request #567576.

function name and go to the corresponding entry.

Part of fixing SF bug #591704.

Part of fixing SF bug #591704.

Part of fixing SF bug #591704.

on Win32, so tests that assume there are such distinctions can't
pass.  Fiddled them to work.

for a __del__ attribute, to see if there's a finalizer.

Weinberg).  This changes all uses of deprecated tempfile functions to
the recommended ones.

Fred, please review!