#6944: the argument to PyArg_ParseTuple should be a tuple, otherwise a SystemError is set.  Also clean up another usage of PyArg_ParseTuple.

does now always result in NULL.

base class positional arguments.

Make the optparse doc style a bit more standard: use standard description units for attrs/methods/etc., and use the correct referencing roles.

UTF-32 stream with a non-raising error handler like "replace" or "ignore".

Note in the intro to Extending... that ctypes can be a simpler, more portable solution than custom C code.

(up to 3.1 times faster in tests), by special-casing base 10 in
_PyLong_Format.  (Backport of r74851 from py3k.)

This works by always setting it in __dict__, except when it's implicitly set in __init__.

non-Apple gcc4.3 and gcc4.4 (because CoreFoundation/CoreFoundation.h
won't compile under non-Apple gcc).

acquiring the import lock around fork() calls. This prevents other threads
from having that lock while the fork happens, and is the recommended way of
dealing with such issues. There are two other locks we care about, the GIL
and the Thread Local Storage lock. The GIL is obviously held when calling
Python functions like os.fork(), and the TLS lock is explicitly reallocated
instead, while also deleting now-orphaned TLS data.

This only fixes calls to os.fork(), not extension modules or embedding
programs calling C's fork() directly. Solving that requires a new set of API
functions, and possibly a rewrite of the Python/thread_*.c mess. Add a
warning explaining the problem to the documentation in the mean time.

This also changes behaviour a little on AIX. Before, AIX (but only AIX) was
getting the import lock reallocated, seemingly to avoid this very same
problem. This is not the right approach, because the import lock is a
re-entrant one, and reallocating would do the wrong thing when forking while
holding the import lock.

Will backport to 2.6, minus the tiny AIX behaviour change.