The following snippet of code is a concise way to exhibit the problem:

import os

wr = open('/tmp/test', 'w')
wr.write('oink\noink\n')
rd = open('/tmp/test', 'r')
rdlns = open('/tmp/test', 'r')
# first, read til EOF is reached (which is right away)
assert len(rd.read()) == 0
assert len(rdlns.readlines()) == 0
# add data to the file
wr.flush()
# try to read again
print 'read     : ', rd.read().split() # fails
print 'readlines: ', rdlns.readlines() # fails
print 'readline : ', rdlns.readline().strip() # succeeds
# cleanup
wr.close()
rd.close()
rdlns.close()
os.remove('/tmp/test')


On Linux, here is the output:
$ python2.6 src/readlines.py
read     :  ['oink', 'oink']
readlines:  ['oink\n', 'oink\n']
readline :  

On Solaris, here is the output:
$ python src/readlines.py
read     :  []
readlines:  []
readline :  oink

The problems comes from the fact that once EOF is reached, nothing more will be read from the file on subsequent reads, as noted in the manual page (http://docs.sun.com/app/docs/doc/816-5168/getchar-3c?a=view):

"If the stream is at end-of-file, the end-of-file indicator for the stream is set and these functions return EOF. For standard-conforming (see standards(5)) applications, if the end-of-file indicator for the stream is set, these functions return EOF whether or not the stream is at end-of-file."

The attached diff fixes the problem.

Thanks for your report. This is not related to ctypes, adjusting component and nosy (per Misc/maintainers.rst); also adding keyword. Can you reproduce it with 3.1 and Subversion checkouts for trunk and py3k? Also, what’s the exact version of your OS?

The patch looks harmless to me, although I'm not sure we're guaranteeing any of the behaviour you are expecting.
Éric, the buffering layer in 3.x is not libc-based, and therefore shouldn't exhibit this particular issue.

This is on Solaris 10, but I also see it on Solaris 8 w/ Python 2.4.
Just tried Python 3.6.1, and it doesn't seem to have that problem.
Python 2.7b2 has the problem.

Antoine:

I'm not sure what the expected behaviour should be either, this is certainly for others more familiar with Python than I to decide.  Although I am certainly annoyed that the current behaviour differs between Solaris and Linux.  Haven't had time to check other platforms to see how things should be.

Also, the behaviour seems inconsistent between the various file methods on Solaris which seems wrong.  Finally, from looking into fileobject.c, clearerr() is used in most places and the omissions (corrected by my patch) do seem unintentional to me, e.g. bugs.

Hope this helps.

FreeBSD is yet another beast:

$ uname -rs
FreeBSD 8.0-STABLE
$ python -V
Python 2.5.5
$ python readlines.py
read     :  []
readlines:  []
readline :

> FreeBSD is yet another beast

Does the patch fix it?

I haven't had a chance to build Python to check, but from the test output I
suspect the problem to be different on FreeBSD.

uname -rs: FreeBSD 9.0-RELEASE-p3 (AMD64)
python -V: Python 2.7.3

`python readline.py:
read     :  ['oink', 'oink']
readlines:  ['oink\n', 'oink\n']
readline :

Without the patch:

read     :  []
readlines:  []
readline :

Is there a test for this we could add? FreeBSD buildbots currently passing all tests

> Is there a test for this we could add?

You could certainly add a test to Lib/test/test_file2k.py.