Possible read()/readline() bug?

[Terry Reedy]

Mike Kent wrote:
> Before I file a bug report against Python 2.5.2, I want to run this by
> the newsgroup to make sure I'm not [missing something].

Good idea ;-).  What you are missing is a rereading of the fine manual 
to see what you missed the first time.  I recommend this *whenever* you 
are having a vexing problem.

> I have a text file of fixed-length records I want to read in random
> order.  That file is being changed in real-time by another process,
> and my process want to see the changes to the file.  What I'm seeing
> is that, once I've opened the file and read a record, all subsequent
> seeks to and reads of that same record will return the same data as
> the first read of the record, so long as I don't close and reopen the
> file.  This indicates some sort of buffering and caching is going on.

In particular, for 2.x
"open( filename[, mode[, bufsize]])
...
The optional bufsize argument specifies the file's desired buffer size: 
0 means unbuffered, 1 means line buffered, any other positive value 
means use a buffer of (approximately) that size. A negative bufsize 
means to use the system default, which is usually line buffered for tty 
devices and fully buffered for other files. If omitted, the system 
default is used.2.3 "

Give open('foo.txt', 'r', 0) a try and see if it makes a difference.

There is a slight change in 3.0. "Pass 0 to switch buffering off (only 
allowed in binary mode)" I presume the restriction is because 't' mode 
is for automatic decoding to unicode and buffering is used for that.

tjr