don't have an access on MIPS machines.  Will be tested by buildbot. :)

list resize, which overallocates.

list.extend tests (they were estimating half the actual use.)

tuples. Lots to be added, still, but this will give big-memory people
something to play with in 2.5 alpha 2, and hopefully get more people to
write these tests.

the one at the end.

After the patch (45590) to add extra debug stats to the gc module, Python
was crashing on OpenBSD due to:
	Fatal Python error: Interpreter not initialized (version mismatch?)

This seems to occur due to calling collect() when initialized (in pythonrun.c)
is set to 0.  Now, the import will occur in the init function which
shouldn't suffer this problem.

uses of it in test_with.py.  As a result, test_with has been skipped
(due to failing imports) on all buildbot boxes since.  Alas, that's
not a test failure -- you have to pay attention to the

    1 skip unexpected on PLATFORM:
        test_with

kinds of output at the ends of test runs to notice that this got
broken.

It's likely that more renaming in test_with.py would be desirable.

this can just call __context__ on the underlying lock.
(The same change for Semaphore does *not* work!)

Patch by Brett Canon, see
https://sourceforge.net/tracker/?func=detail&atid=532156&aid=1475959&group_id=71702

MAXPATHLEN-sized buffers for various output-buffers (like to realpath()),
and that's correct on BSD platforms, but not Linux (which uses PATH_MAX, and
does not define MAXPATHLEN.) Cursory googling suggests Linux is following a
newer standard than BSD, but in cases like this, who knows. Using the
greater of PATH_MAX and 1024 as a fallback for MAXPATHLEN seems to be the
most portable solution.

AF_PACKET cases in getsockaddrarg were missing their own checks for
tuple-ness of the address argument, which means a confusing SystemError was
raised by PyArg_ParseTuple instead.

The new char-array used in ioctl calls wasn't explicitly NUL-terminated;
quite probably the cause for the test_pty failures on Solaris that we
circumvented earlier. (I wasn't able to reproduce it with this patch, but it
has been somewhat elusive to start with.)

terminology in the alpha 1 documentation.

 - "context manager" reverts to its alpha 1 definition
 - the term "context specifier" goes away entirely
 - contextlib.GeneratorContextManager is renamed GeneratorContext

There are still a number of changes relative to alpha 1:

  - the expression in the with statement is explicitly called the
    "context expression" in the language reference
  - the terms 'with statement context', 'context object' or 'with
    statement context' are used in several places instead of a bare
    'context'. The aim of this is to avoid ambiguity in relation to the
    runtime context set up when the block is executed, and the context
    objects that already exist in various application domains (such as
    decimal.Context)
  - contextlib.contextmanager is renamed to contextfactory
    This best reflects the nature of the function resulting from the
    use of that decorator
  - decimal.ContextManager is renamed to WithStatementContext
    Simple dropping the 'Manager' part wasn't possible due to the
    fact that decimal.Context already exists and means something
    different. WithStatementContext is ugly but workable.

A technically unrelated change snuck into this commit:
contextlib.closing now avoids the overhead of creating a
generator, since it's trivial to implement that particular
context manager directly.

Edward Loper.

an installed VC6. Otherwise only the first such tree gets checked and this
warning doesn't get displayed.

'context specifier' in a few places

Fix broken contextlib test from last checkin (I'd've sworn I tested that before checking it in. . .)