filename: good. It's saved already so should be accessible.
lineno: useful, but has one problem: it can't always be correct.
Keeping it up-to-date after read() is possible but may slow read() of
large files down a bit; keeping it up-to-date after seek() is
(realistically speaking) impossible. And a minor detail: should it
represent the number of lines read so far or the number of the next
line?
Suggestion: make it a writable attribute, initialized to 0; set to -1
by seek(); if it's -1, it's left unchanged by read() and readline();
if >= 0, readline() bumps it by 1, read() bumps it by the number of \n
characters in the string read. Well, why not do the same for
writeline() and write()... Finally, initialize it to -1 when the file
is opened with mode 'rb' or 'wb'. I suggest that the filename be made
a writable attribute as well -- might be useful to cheat etc.
peek functions: I'm less convinced that this is worth the additional
complexity -- and I've a feeling that it might encourage bad style (oh
there he goes again I hear some of you thinking :-). On the other
hand it might be a good idea. I've a suggestion for a slightly
different style of interface: f.peekline() would return the next
unpeeked line and f.peekline(n) would return the n'th line (counting
from 0, obviously). I don't see when f.peekreset() would be necessary
-- for definiteness, code should always use f.peekline(n) if there may
be different pieces of code peeking in the same file. Maybe
f.peekline() should mean f.peekline(n+1) when called after
f.peekline(n) if I understand correctly how you would use this most of
the time.
If you end up implementing this, I'd love to receive patches!
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>