[Python-3000] iostack, second revision

[Anders J. Munch]

Nick Coghlan wrote:
 > Jim Jewett wrote:
 >> Why not just borrow the standard symbolic names of cur and end?
 >>
 >>     seek(pos=0)
 >>     seek_cur(pos=0)
 >>     seek_end(pos=0)

I say drop seek_cur and seek_end altogether, and keep only absolute
seek.

The C library caters for archaic file systems, that are record-based
or otherwise not well modelled as an array of bytes.  That's where the
ftell/fseek/fpos_t system comes from: An fpos_t might be a composite
data type containing a record number and a within-record offset; but as
long as it's used as an opaque token, you'd never notice.

That was a nice design for backward-compatibility back in the early
1970's.  Thirty years later do we still need it?  POSIX and Win32 have
array-of-bytes files.  Does CPython even run on any OS where binary
files are not seen as arrays of bytes?  I'm saying _binary_ files
because a gander through the standard library shows that seeking is
never done on text files.  Even mailbox.py opens Unix mailbox files as
binary.

The majority of f.seek(.., 2) calls in the library use it for computing
the length of file.  How's that for an "opaque token": f.tell() is
taken to be the length of the file after f.seek(0,2).

As for seeking to the end with only an absolute .seek available:
Surely, any file that supports seeking to the end will also support
reporting the file size.  Thus
  f.seek(f.length)
should suffice, and what could be clearer?  Also, there's the "a+w"
mode for appending, no seeks required.

Having just a single method/mode will not only ease file-protocol
implementation, but IMO client code will be easier to read as well.

- Anders

PS: I'm working on that FileBytes object, Tomer, as a wrapper over an
object that supports seek to absolute position, with integrated
buffering.