i_divmod():  As discussed on Python-Dev, changed the overflow
checking to live happily with recent gcc optimizations that
assume signed integer arithmetic never overflows.

This differs from the corresponding change on the 2.5 and 2.4
branches, using a less obscure approach, but one that /may/
tickle platform idiocies in their definitions of LONG_MIN.
The 2.4 + 2.5 change avoided introducing a dependence on
LONG_MIN, at the cost of substantially goofier code.

Debian sparc buildbots.  Since this goes through a lot of tests
and hits the disk a lot it could be slow (especially if NFS is involved).
I'm not sure if that's the problem, but printing periodic msgs shouldn't hurt.
The code was stolen from test_compiler.

Needs backport to 2.5.1 and earlier.

- various minor cleanups for improved consistency

have all new files use 4 spaces (to match current PEP 7 style).

Backport candidate.

Remove the old decimal context management tests from test_contextlib (guess who didn't run the test suite before committing...)

Fix the wrongheaded implementation of context management in the decimal module and add unit tests. (python-dev discussion is ongoing regarding what we do about Python 2.5)

Backport candidate for 2.5.

This should probably go into Python 2.5 or 2.5.1 as well.

  OS speicifc path modules import them.
- Have os2emxpath import common functions fron ntpath instead of using copies

whitespace in expected output.  Stop that.

bogus bytecode.  It is unclear whether this is a real bug or a "won't
fix" case like bogus_code_obj.py.

Since MSVC doesn't know about .asm files, a helper batch file is needed
to find ml64.exe in predefined locations.  The helper script hardcodes
the path to the MS Platform SDK.

Will backport to 2.5.

array.__deepcopy__() needs to take an argument, even if it doesn't actually
use it. Will backport to 2.5 and 2.4 (if applicable.)

OverflowError while x*x succeeds and produces infinity; apparently
these inconsistencies cannot be fixed across ``all'' platforms and
there's a widespread feeling that therefore ``every'' platform
should keep suffering forevermore.  Ah well.