Due to interaction between the MSL C library and the GUSI I/O library I can get reads from sockets to work consistently either for unbuffered binary files or for buffered binary files, but not for both:-(

The workaround is to force socket.makefile() to disable buffering for binary files.

Fixes bug 534625. 2.2.1 candidate.

Fix whitespace on a line also.

'94, demonstrating a thread bug that was later repaired via Python growing
an internal import lock.  It's of no current interest, and the now-std
test_threaded_import.py is pretty much the same test.

ever do, they can damn well #define _POSIX_THREADS their own damn selves.

Weaklink most toolbox modules, improving backward compatibility. Modules will no longer fail to load if a single routine is missing on the curent OS version, in stead calling the missing routine will raise an exception.

Should finally fix 531398. 2.2.1 candidate.

Weaklink most toolbox modules, improving backward compatibility. Modules will no longer fail to load if a single routine is missing on the curent OS version, in stead calling the missing routine will raise an exception.

Should finally fix 531398. 2.2.1 candidate.

Also blacklisted some constants with definitions that were not Python-compatible.

slash on strings like "http://www.python.org/ is good".

Weaklink most toolbox modules, improving backward compatibility. Modules will no longer fail to load if a single routine is missing on the curent OS version, in stead calling the missing routine will raise an exception.

Should finally fix 531398. 2.2.1 candidate.

TemporaryFile.  This flag causes the fd to be closed on exec().

see bug 411881

This fixes the symptom, but PRINT_ITEM has no way to know what (if
anything) PyFile_WriteObject() writes unless the object being printed
is a string.  When the object isn't a string, this fix retains the
guess that softspace should be set after PyFile_WriteObject().
We might want to say that it's the job of filelike-object write methods
to leave the file's softspace in the correct state.  That would probably
be better -- but everyone relies on PRINT_ITEM to guess for them now.

that can be raised - do_help won't be called if arg is not a string

as the fully qualified local hostname.

This in inside the test so it really doesn't matter much.  Closes
SF patch 497097.

Closes SF patch 494871.

Clarify the docstring for get_history_length.  Closes SF patch 494066.

Assorted:  bump the serial number via a trivial new bumpserialno()
function.  The point is to give a single place to set a breakpoint when
waiting for a specific serial number.

of get_line.  This makes test_bufio finish in 1.7 seconds instead of 57
seconds on my machine (with Py_DEBUG defined).

Also, rename the local variables n1 and n2 to used_v_size and
total_v_size.

When WITH_PYMALLOC is defined, define PYMALLOC_DEBUG to enable the debug
allocator.  This can be done independent of build type (release or debug).
A debug build automatically defines PYMALLOC_DEBUG when pymalloc is
enabled.  It's a detected error to define PYMALLOC_DEBUG when pymalloc
isn't enabled.

Two debugging entry points defined only under PYMALLOC_DEBUG:

+ _PyMalloc_DebugCheckAddress(const void *p) can be used (e.g., from gdb)
  to sanity-check a memory block obtained from pymalloc.  It sprays
  info to stderr (see next) and dies via Py_FatalError if the block is
  detectably damaged.

+ _PyMalloc_DebugDumpAddress(const void *p) can be used to spray info
  about a debug memory block to stderr.

A tiny start at implementing "API family" checks isn't good for
anything yet.

_PyMalloc_DebugRealloc() has been optimized to do little when the new
size is <= old size.  However, if the new size is larger, it really
can't call the underlying realloc() routine without either violating its
contract, or knowing something non-trivial about how the underlying
realloc() works.  A memcpy is always done in this case.

This was a disaster for (and only) one of the std tests:  test_bufio
creates single text file lines up to a million characters long.  On
Windows, fileobject.c's get_line() uses the horridly funky
getline_via_fgets(), which keeps growing and growing a string object
hoping to find a newline.  It grew the string object 1000 bytes each
time, so for a million-character string it took approximately forever
(I gave up after a few minutes).

So, also:

fileobject.c, getline_via_fgets():  When a single line is outrageously
long, grow the string object at a mildly exponential rate, instead of
just 1000 bytes at a time.

That's enough so that a debug-build test_bufio finishes in about 5 seconds
on my Win98SE box.  I'm curious to try this on Win2K, because it has very
different memory behavior than Win9X, and test_bufio always took a factor
of 10 longer to complete on Win2K.  It *could* be that the endless
reallocs were simply killing it on Win2K even in the release build.

getuid or getpid.  posix_getuid & posix_getpid never raise exceptions when
called with no args.