A bug with file.tell()?

Paul Watson pwatson at redlinepy.com
Fri Sep 10 12:45:51 EDT 2004


"Nick Jacobson" <nicksjacobson at yahoo.com> wrote in message
news:f8097096.0409100344.2594797b at posting.google.com...
> It gets weirder:
>
> I added the second fp.read(3) statement below.  And that statement
> doesn't print anything out!  It (fp.read(3)) thinks it's at the end of
> the file, while the next statement "for line in fp" thinks it's not
> (and reads "asdf")!
>
> Now I'm definitely confused.
>
>
>
> fp = file("testcrlf.txt")
> #read in some of the file:
>
> print fp.read(3)
> for line in fp:
>     if line == "blah3\n":
>         break
> fpos = fp.tell() #save the current position...
>
> print fp.read(3)
> for line in fp:
>     print line #prints "asdf", so it wasn't at the end of the file
>
> fp.seek(fpos) #rewind?
> for line in fp:
>     print line #prints nothing, because it's at the end of the file!

The first "for line in fp" created an iterator for the file that has a
read-ahead buffer.  While your loop operated on one line at a time, under
the covers the iterator read more of the file to improve speed performance.
With a file of this size, it is likely that the entire file was read at
once.  Because of that, the file pointer was already at the end of file.

The fact that your loop had only processed three of the lines is not know to
File.tell().

Is this a bug?  While it is documented, it means that tell() and seek()
cannot be used if a file is processed by an iterator.  The documentation for
seek() says that "only offsets returned by tell() are legal."  One person's
documented behavior is another person's bug.  The documentation for tell()
should probably mention this fact.





More information about the Python-list mailing list