This is important IMO because httplib reads the headers this way.

observation that _rbuf could never have more than one string in it.
So make _rbuf a string.  The code branches for size<0 and size>=0
are completely separate now, both in read() and in readline().

I checked for tabs this time. :-)

to being a new-style class, to be more similar to the socket class
in the _socket module; it is now the same as the _socketobject class.
Added __slots__.  Added docstrings, copied from the real socket class
where possible.

The _fileobject class is now also a new-style class with __slots__
(though without docstrings).  The mode, name, softspace, bufsize and
closed attributes are properly supported (closed as a property; name
as a class attributes; the softspace, mode and bufsize as slots).

(Synched from pyunit CVS)

couple of minor edits elsewhere.

I believe I introduced this bug when I refactored the reversal code so
that the mergesort could use it too.  It's not a problem on the 2.2 branch.

correctly (the test at least succeed, but they don't test everything yet).

Also fix a performance problem in read(-1): in unbuffered mode, this would
read 1 byte at a time.  Since we're reading until EOF, that doesn't make
sense.  Use the default buffer size if _rbufsize is <= 1.

prints function and module names, which is more informative now that
we repeat some tests in slightly modified subclasses.

Add a test for read() until EOF.

Add test suites for line-buffered (bufsize==1) and a small custom
buffer size (bufsize==2).

Restructure testUnbufferedRead() somewhat to avoid a potentially
infinite loop.

destructor early.

subtype_dealloc().

When call_finalizer() failed, it would return without going through
the trashcan end macro, thereby unbalancing the trashcan nesting level
counter, and thereby defeating the test case (slottrash() in
test_descr.py).  This in turn meant that the assert in the GC_UNTRACK
macro wasn't triggered by the slottrash() test despite a bug in the
code: _PyTrash_destroy_chain() calls the dealloc routine with an
object that's untracked, and the assert in the GC_UNTRACK macro would
fail on this; but because of an earlier test that resurrects an
object, causing call_finalizer() to fail and the trashcan nesting
level to be unbalanced, so _PyTrash_destroy_chain() was never called.
Calling the slottrash() test in isolation *did* trigger the assert,
however.

So the fix is twofold: (1) call the GC_UnTrack() function instead of
the GC_UNTRACK macro, because the function is safe when the object is
already untracked; (2) when call_finalizer() fails, jump to a label
that exits through the trashcan end macro, keeping the trashcan
nesting balanced.

The -tt means modules that mix tabs and spaces will be rejected.
The -E refuses to believe Python options in the environment.

empty heap, since heap[0] raises the appropriate IndexError already.

is empty.

the weakreflist to NULL in the constructor and to fill the tp_flags
slot with Py_TPFLAGS_HAVE_WEAKREFS.  Closes SF bug 586583.

the classes' attribute list.

and this broke a Zope "pipelining" test which read multiple responses
from the same connection (this attaches a new file object to the
socket for each response).  Added a test for this too.

(I want to do some code cleanup too, but I thought I'd first fix
the problem with as little code as possible, and add a unit test
for this case.  So that's what this checkin is about.)

  in stead of prepending it, which messes up "import * from".
- A few ascii()s added again.
- Changed the getbaseclasses a little, but it still isn't perfect.

__nonzero__(), in response to SF bug #579991.

the result passes through backticks.

This patch makes inheritance for OSA classes work. The implementation is a
bit convoluted, but I don't immedeately see a simpler way of doing it.

I added calls to ascii() everywhere we output strings that may contain
non-ascii characters (Python has gotten very picky since the encoding
patch:-).

I also removed Donovan's different way of opening resource files: I don't
seem to need it.

sample code, and the note was marked as a logical thing.

WSAEWOULDBLOCK, the second connect() attempt appears to yield WSAEISCONN
on Win98 but WSAEINVAL on Win2K.  So accept either as meaning "yawn,
fine".  This allows test_socket to succeed on my Win2K box (which it
already did on my Win98SE box).