[Python-3000] iostack, second revision
ncoghlan at gmail.com
Fri Sep 8 12:31:48 CEST 2006
>> Why not use tell() and seek() instead of get_pointer() and
> because, at least the way i see it, seek and tell are byte-oriented,
> while the upper layers of the stack may be objects-oriented
> (including, for instance, characters, struct records, or pickled objects),
> so pointers would be a vector of (byte-position, stateful object-layer info).
> pointers are different than mere byte-positions, so i thought streams
> should have a byte-level API, while the upper layers are more likely
> to work with "pointers".
seek() & tell() aren't necessarily byte-oriented, and a program can get itself
in trouble by treating them as if they are. Seeking to an arbitrary byte
position on a Windows text file can be a very bad idea :)
So -1 on using different names, but +1 on permitting different IO layers to
assign a different meaning to exactly what it is that seek() and tell() are
With the IO layer doing a translation, I suggest that the seek/tell cookies
should be plain integers, so that doing f.seek(20) on a text file will seek to
the 20th character instead of the 20th byte. This approach is backwards
compatible with the current rule of 'for text files, arguments to seek() must
be previously returned from tell()' and Guido's desire that f.seek(0) always
seek to the beginning of the file.
>> Seek should also support several special cases:
>> f.seek(0) seeks to the start of the file no matter what type is
>> otherwise used for pointers ("seek cookies" ?), f.seek(0, 1) is a
>> no-op, f.seek(0, 2) seeks to EOF.
>> Perhaps it would be good to drop those magic numbers (0, 1, 2) for
>> seek() ? They don't really help readibility except perhaps for people
>> who still do a lot of C ;)
Since I've been playing with string methods lately, I believe a natural name
for the 'seek from the end' version is f.rseek(0). And someone else suggested
f.seekby(0) as a reasonable name for relative seeking.
f.seek(0) # Go to beginning
f.seekby(0) # Stay at current position
f.rseek(0) # Go to end
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-3000