In response to "shouldn't the client close the file?", the answer is
"no". The original design behind HTTPConnection is that the client did
not have to worry about it. The response would close itself when you
read the last of the data from it. This closing also dealt with
allowing the connection to perform another request/response (if it was
a persistent connection).

However... the auto-close behavior broke compatibility with the
classic httplib.HTTP class' behavior when a zero-length response body
was present. In that situation, the HTTPResponse object was
auto-closing it since there was no data present, and for an HTTP/1.0
connection-close socket (or an HTTP/0.9 request) connection, that also
ended up closing the socket. When an httplib.HTTP user went to read
the socket... boom. A patch to correct the auto-close (for compat with
old httplib users) was added in rev 1.22.

But for non-zero-length *chunked* bodies, we should keep the
auto-close behavior. The library user is not reading the socket (they
can't cuz of the chunked response we just got done handling), so they
should be immune to the response closing the socket. In fact, I would
like to see (one day) the auto-close restored, and the HTTP subclass
would simply have a flag to disable that behavior (for back-compat
purposes).

IOBinding.encoding. Also set sys.std{in,out,err}.encoding, for both
the local and the subprocess case.

fix the hangs on Win98SE when starting IDLE via "python" from a DOS box,
but did appear to make them harder to provoke.  I closed that bug report
as being hopeless (and if someone wants to open it again, don't dare
assign it to me again <0.1 wink>).

DESTDIR being non-null.

Fixes #700827

Also add force, to recompile string.pyc in DESTDIR (which would normally
compiled by running compileall.py).

to the script. Fixes #757544.

instead of rfc822 as the Message factory.

- move the normpath stuff around a bit
- added dubious special case to addPythonFramework()

xxxMODE flags don't cut it. Also set the umask to 2 before doing the
compileall on the destination system.

executable in the bundle. Therefore got rid of the "binaries" attribute.

framework. Fixes #758112.

It depended on the previously removed basic block checker to
prevent a jump into the middle of the transformed block.

Clears SF 757818: tuple assignment -- SystemError: unknown opcode

of type .py, .pyw and .pyc. If not, post a warning.

the DESTDIR patch. Fixed.

From gcov's output (based on a locally changed _sre.c):

  82.07% of 1372 source lines executed in file ./Modules/_sre.c

extensions on top of Python 2.2 no longer seems feasible.

and not part of a normal frameworkinstall) that installs Demo and Tools
and a readme file into /Applications/MacPython-2.3/Extras. This will
give people access to the demos and tools if they instal Python through
the binary installer.

paths.

aligned.

From SF patch #757058.

explaining what's wrong with the two simpler variants.