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. _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
