Also includes doc updates mentioning that these entries may not
be retrievable via getgrnam and getgrgid.

Patch by Bobby Impollonia.

OSError exception when The OS had been told to ignore SIGCLD in our process
or otherwise not wait for exiting child processes.

Passing the port as a string value works fine in regular mode, but
if you turned debug on it would throw an error trying to print the
port number, which is surprising and confusing.

Issue #7213: Change the close_fds default on Windows to better match the new
default on POSIX.  True when possible (False if stdin/stdout/stderr are
supplied).

Update the documentation to reflect all of the above.

Thanks to Garrett Cooper for the fix.

Also document the use of three-tuples if control of the charset
and language is desired.

$LDVERSION, which screws up the sym/hard-links.  This avoids those games when
$VERSION == $LDVERSION.

Also, include a drive-by fix for an obvious syntax error.

the C code, using pipe2() when available.  Adds unittests for close_fds and
cloexec behaviors.

platform basis.  It remains False on Windows and changes to True on all
other platforms (POSIX).  Based on python-dev discussion and
http://bugs.python.org/issue7213.

When the solution is converted to Visual Studio 2010, the command line to invoke make_buildinfo changes from:
$(SolutionDir)make_buildinfo.exe" Debug "$(IntDir)\"
to
$(SolutionDir)make_buildinfo.exe" Debug "$(IntDir)"
If the final backslash is omitted, the backslash in IntDir will escape the quote, thus passing the quote in as part of the path name.

This solution is a hack-fix to that problem by skipping any trailing quote from the path name.  It works as long as we don't need any additional arguments to make_buildinfo.exe.  This will help all those sould that are going to run this project through the visual studio autoconverter and get the same error.

The rearranged code should do exactly what the old code did, but
the new code avoids a potentially costly re computation in the case
where a boundary already exists.

Issue #10188 (partial resolution): tidy up some behaviour in the new tempfile.TemporaryDirectory context manager