| msg106999 - (view) |
Author: Christophe Kalt (kalt) |
Date: 2010-06-03 23:50 |
| 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. |
|
|
| msg107007 - (view) |
Author: Éric Araujo (eric.araujo) *  |
Date: 2010-06-04 05:49 |
| 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? |
|
|
| msg107027 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2010-06-04 11:33 |
| 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. |
|
|
| msg107035 - (view) |
Author: Christophe Kalt (kalt) |
Date: 2010-06-04 11:59 |
| 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. |
|
|
| msg107037 - (view) |
Author: Christophe Kalt (kalt) |
Date: 2010-06-04 12:06 |
| 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. |
|
|
| msg107106 - (view) |
Author: Christophe Kalt (kalt) |
Date: 2010-06-04 22:39 |
| FreeBSD is yet another beast: $ uname -rs FreeBSD 8.0-STABLE $ python -V Python 2.5.5 $ python readlines.py read : [] readlines: [] readline : |
|
|
| msg107238 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2010-06-06 21:58 |
| > FreeBSD is yet another beast Does the patch fix it? |
|
|
| msg108429 - (view) |
Author: Christophe Kalt (kalt) |
Date: 2010-06-22 23:09 |
| 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. |
|
|
| msg166046 - (view) |
Author: Kubilay Kocak (koobs)  |
Date: 2012-07-21 16:37 |
| 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 |
|
|
| msg166067 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2012-07-21 20:50 |
| > Is there a test for this we could add? You could certainly add a test to Lib/test/test_file2k.py. |
|
|