returning a 0-byte file -- raise an IOError instead.
Original patch from Phil Knirsch.

in urllib and using the other ``_proxy`` env vars.
Original patch by Donovan Baarda.

custom formatting of contents via subclassing PrettyPrinter.

blatant lie in a docstring (it is not useful for security regardless of
how you spell it).

type of encrypted zip files.  Files using extended local headers
needed to compare the check byte against different values.  (according
to reading the infozip unzip crypt.c source code)

Fixes issue1003.

Fix an off-by-one error I noticed.

that have file headers past the 2**31 byte boundary.

subprocess.list2cmdline (windows).

try:
  ...
except:
  ...
  raise
else:
  ...

the else: is unecessary due to the blind except: with a raise.

kicked in during the critical section.  solution: disable gc during
that section.  Patch contributed by jpa and updated by me to cover the
race condition still existing what therve from twistedmatrix pointed
out (already seen and fixed in twisted's own subprocess code).

for inside of the final if needquotes: within subprocess.list2cmdline().

a default timeout has been set, by using getsockopt() to get the error
condition (instead of trying another connect() call, which seems to be
a Linuxism).

2.5 bugfix candidate, assuming no one reports any problems with this change.

ignoring errors, and use this in subprocess to speed up
subprocess creation in close_fds mode. Patch by Mike Klaas.

2.5.2 bugfix candidate.

Patch by Quentin Gallet-Gilles.

Fixes the tokenizer, tokenize.py and int() to reject this.
Patches by Malte Helmert.

coma to trace.py in the same --ignore-module option.
Thanks Raghuram Devarakonda.

Contributed by John Lenton.

I also disabled a test in test_ssl which requires network access to svn.python.org. This fixes a bug Skip has reported a while ago.

.handle_timeout() method when no requests are received within the timeout period.

Added unit test to verify that threading.local doesn't cause ref leaks. It seems that the thread local storage always keeps the storage of the last stopped thread alive. Can anybody comment on it, please?