I find that file.tell returns not the byte offset of the next byte, but
possibly the byte offset of the next block to be read. I find it always
to be a multiple of 1024. Following is a demo of the bug. where I read a
 few lines into a text file, step back by the length of the last read
line, read again, and do not find the same data. What is returned is the
tail part of a line way down  in the file. I woeked around by keeping
track of the file pointer, and seek worked fine. tell() is at fault.
----------demonstration on a text file
Python 2.5.1 (r251:54863, Nov 14 2007, 16:00:54) 
[GCC 3.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> jf=open('junk','r')
>>> line=jf.next()
>>> line
'\n'
>>> line=jf.next()
>>> line
'See COPYING file in the same directory as this one for license.\n'
>>> line=jf.next()
>>> line
'\n'
>>> line=jf.next()
>>> line
'Thank you for trying this utility. I had great fun putting it\n'
>>> line=jf.next()
>>> line
'together, and I hope users will find it useful.\n'
>>> jf.seek(len(line),1)
>>> line=jf.next()
>>> line
'gle says Maps will not work without it. file:// URLs are \n'

See the documentation for file.next 
(http://docs.python.org/library/stdtypes.html#file.next).  As you can 
see, file.next uses a buffer which will mess with the result of other 
methods, such as file.tell.

O.K. But, is there a way to backtrack to the beginning of the last read
line, without explicitly implementing accounting of the real file
pointer in the code, and doing "seek(<file pointer>,0)"? 

The documentation you pointed to implies that, in "for name in file:"
loop a clean backtracking is not possible. Am I missing something?

Thanks.

Try using the readline method instead of next.  I don't think that 
applies the same buffering.