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).

file in unix-Python.

This is inspired by SF patch 581742 (by Jonathan Hogg, who also
submitted the bug report, and two other suggested patches), but
separates the non-GC case from the GC case to avoid testing for GC
several times.

Had to fix an assert() from call_finalizer() that asserted that the
object wasn't untracked, because it's possible that the object isn't
GC'ed!

Fix forthcoming.

Closes SF bug #586937.

Py_UNICODE.

width of Py_UNICODE.  Good catch, MAL.

same idea as getting rid of GETCONST & GETNAME (see patch #506436)

version to 1.1.4 (because of the 1.1.3 security problem).  Also
replace a funny use of line.find() with line.startswith().

machine -- that feels just right.

is no longer unused in type objects.

module).  (One thing remains to be done: the gzip class has an
xreadline method; this ought to be replaced by an iterator as well.)

string of longer than 1 character.

are obsolete.

ValueError when called for a closed file.

For a file f, iter(f) now returns f (unless f is closed), and f.next()
is similar to f.readline() when EOF is not reached; however, f.next()
uses a readahead buffer that messes up the file position, so mixing
f.next() and f.readline() (or other methods) doesn't work right.
Calling f.seek() drops the readahead buffer, but other operations
don't.

The real purpose of this change is to reduce the confusion between
objects and their iterators.  By making a file its own iterator, it's
made clearer that using the iterator modifies the file object's state
(in particular the current position).

A nice side effect is that this speeds up "for line in f:" by not
having to use the xreadlines module.  The f.xreadlines() method is
still supported for backwards compatibility, though it is the same as
iter(f) now.

(I made some cosmetic changes to Oren's code, and added a test for
"file closed" to file_iternext() and file_iter().)

if we are running in an OSX framework enabled build directory, test that
the framework infrastructure exists. This catches the very common
error of doing "make install" in stead of "make frameworkinstall".

at compile time: use PBGetCatInfoSync() to get FInfo data in stead of
GetFInfo. The latter doesn't work for folders. The former does, at
least on OSX, and insofar the info makes sense for a folder.

Document heapq module
Add PEP263 section (not sure I really understand the PEP's effect on 8-bit
   strings, though -- will have to experiment with it)