Logged In: YES 
user_id=1417712

i haven't ecnountered this edge case either, in my c days or
otherwise. for those who are familiar with this (and in
python's case, realize what the underlying implementation
is), it simply wouldn't occur to them to *omit* flushes.

this issue actually cropped up in a unit test in twisted
which was failing on windows and not failing elsewhere.

the explanation of read() and why this isn't working as i
initially expected makes sense. however, this is what python
docs say:

"Read at most size bytes from the file (less if the read
hits EOF before obtaining size bytes). If the size  argument
is negative or omitted, read all data until EOF is reached.
The bytes are returned as a string object. An empty string
is returned when EOF is encountered immediately. (For
certain files, like ttys, it makes sense to continue reading
after an EOF is hit.) "

this states, absolutely unequivocally, that the first read
does 'encounter' or 'hit' EOF.

as i stated previously, the correct solution in my view is
to handle this for the users. however, in light of the issue
of extensions doing their own thing, doing this would
require making extensions use python's fread wrapper. this
is unlikely (understatement *ahem*) to happen.

as such, this becomes a documentation issue. users should be
made aware that they are expected to deal with this.
ideally, they would also be told what to do. wording in the
read() docs should be corrected to remove any implication
that EOF actually gets encountered in the sense of ansi c
until "" is returned.

make sense?

-p