doesn't cause the exception, but the close() does.

Will backport.

and not trying to connect before.

this might fix the problem.

the original code object backing the generator. Patch by Collin Winter.

as the documentation says.

Saves the unnecessary creation of a tuple as intermediate container.

Make PySet_Add() work with frozensets.  Works like PyTuple_SetItem() to build-up values in a brand new frozenset.

that shouldn't cause the test to fail.  Just like it setUp.

global to determine when the server is ready to be used.  This slows the test
down, but should make it correct.  There was a race condition before where the
server could have assigned a port, yet it wasn't ready to serve requests.  If
the client sent a request before the server was completely ready, it would get
an exception.  There was machinery to try to handle this condition.  All of
that should be unnecessary and removed if this change works.  A NOTE was
added as a comment about what needs to be fixed.

The buildbots will tell us if there are more errors or
if this test is now stable.

by retrying the host for up to 3 times.

test_distutils still fails when doing that.

it was released, but that reversion never made it to the Py2.6 head.

Added the Python core headers Include/*.h and pyconfig.h as dependencies for the extensions in Modules/
It forces a rebuild of all extensions when a header files has been modified

Backport of several functions from Python 3.0 to 2.6 including PyUnicode_FromString, PyUnicode_Format and PyLong_From/AsSsize_t. The functions are partly required for the backport of the bytearray type and _fileio module. They should also make it easier to port C to 3.0.
First chapter of the Python 3.0 io framework back port: _fileio
The next step depends on a working bytearray type which itself depends on a backport of the nwe buffer API.

and eliminate a compiler warning in floatobject.c.  There might be
a better way to go about this, but it should be good enough for now.

in case there were transient failures.  This will hopefully silence
the buildbots for this test.  As we find other tests that have a problem,
we can fix with a similar strategy assuming it is successful.  It worked
on my box in a loop for 10+ runs where it would have an exception otherwise.

whole construct away, even when an 'else' clause is present::

    while 0:
        print("no")
    else:
        print("yes")

did not generate any code at all.

Now the compiler emits the 'else' block, like it already does for 'if' statements.

Will backport.