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.

Now that COMMENT tokens are reliably followed by NL or NEWLINE,
there is never a need to add extra newlines in untokenize.

Small: Always generate a NL or NEWLINE token following
       a COMMENT token.  The old code did not generate an NL token if
       the comment was on a line by itself.

Large: The output of untokenize() will now match the
       input exactly if it is passed the full token sequence.  The
       old, crufty output is still generated if a limited input
       sequence is provided, where limited means that it does not
       include position information for tokens.

Remaining bug: There is no CONTINUATION token (\) so there is no way
for untokenize() to handle such code.

Also, expanded the number of doctests in hopes of eventually removing
the old-style tests that compare against a golden file.

Bug fix candidate for Python 2.5.1. (Sigh.)

inf) but didn't; added a test to test_float to verify that, and ignored the
ERANGE value for errno in the pow operation to make the new test pass (with
help from Marilyn Davis at the Google Python Sprint -- thanks!).