Title: Flushing the standard input causes an error
Type: behavior Stage: resolved
Components: Interpreter Core Versions: Python 2.7
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: belopolsky Nosy List: belopolsky, eric.araujo, jcea, nadeem.vawda, ned.deily,, rogerbinns, terry.reedy, vstinner
Priority: normal Keywords:

Created on 2011-04-15 13:41 by, last changed 2011-04-16 16:49 by rogerbinns. This issue is now closed.

Messages (9)
msg133821 - (view) Author: Nadeem Vawda (nadeem.vawda) * (Python committer) Date: 2011-04-15 13:44
Could you provide more details on the problem? What version of Python did
you encounter this error under? A short code fragment that triggers the
error would also be useful.

(I get no errors executing "sys.stdin.flush()" on 2.6.6 or 3.3)
msg133828 - (view) Author: Edzard Pasma ( Date: 2011-04-15 14:45

The error occured in the APSW shell, when using its .output command. Looking at the apsw source, it appears to perform a sys.stdin.flush() at that point. Trying this in the Python interpreto gives the same error:

$ python
Python 2.7.1 (r271:86882M, Nov 30 2010, 09:39:13) 
[GCC 4.0.1 (Apple Inc. build 5494)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.stdin.flush
<built-in method flush of file object at 0x28020>
>>> sys.stdin.flush()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 9] Bad file descriptor

But in Python3 it no longer occurs. I'd like to report this to the developer of the APSW module as it appears most easy to avoid it there (also there are more frequent releases). I hope it is useful to report it here too.

Regards, E. Pasma
(sorry that the original post was empty)
msg133861 - (view) Author: Jesús Cea Avión (jcea) * (Python committer) Date: 2011-04-15 18:24
I can't reproduce this Under Solaris 10 or Ubuntu. Maybe is it something Apple related?.

Anyway, does it makes sense to flush sys.stdin, at all?.
msg133869 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2011-04-15 19:52
I get the same:

$ python2.7
Python 2.7.1 (r271:86882M, Nov 30 2010, 10:35:34) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.stdin.flush()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 9] Bad file descriptor

I'll look further.
msg133871 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2011-04-15 20:09
In python 2.x, sys.stdin.flush() is more or less equivalent to C fflush(stdin).  The behavior of fflush() on streams that are open for reading only is undefined. [1]

Python 3.x io does not use C stdio library and therefore it is not surprising that the behavior is different.

msg133874 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2011-04-15 21:10
Python 2.7.1  ... 32 bit (Intel)] on win32
>>> import sys
>>> sys.stdin.flush()

stdin.flush() could mean to clear (discard) the input buffer. Given that it is undefined, the puzzle is that it exists at all, even to be called. 
Consistency across platforms is why we wrote io for Py3. Agreed not a bug for 2.x.
msg133876 - (view) Author: Edzard Pasma ( Date: 2011-04-15 22:39
Thanks a lot, especially for making clear what flushing an input stream means (or that it is meaningless). I hope it will be solved in APSW, there is an issue now:
msg133883 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2011-04-16 06:33
"Given that it is undefined, the puzzle is that it exists at all, even to be called."  No puzzle at all: in Python 2, stdin is a file object which automatically has a flush method. And the behavior seen here is not limited to OS X; FreeBSD, for one, gives exactly the same error.
msg133898 - (view) Author: Roger Binns (rogerbinns) Date: 2011-04-16 16:49
I'm the APSW author.  The reason why this apparent nonsense is done is due to using readline and completion.  That requires being able to write to standard input when it is a terminal - something that Windows and Linux are happy to do.

In any event I'll put a try/catch around this and ignore.
Date User Action Args
2011-04-16 16:49:14rogerbinnssetnosy: + rogerbinns
messages: + msg133898
2011-04-16 06:33:16ned.deilysetnosy: + ned.deily
messages: + msg133883
components: - macOS
2011-04-15 22:39:06pasma10@concepts.nlsetmessages: + msg133876
2011-04-15 21:10:54terry.reedysetnosy: + terry.reedy
messages: + msg133874
components: + macOS
2011-04-15 20:09:19belopolskysetstatus: open -> closed
versions: + Python 2.7
messages: + msg133871

components: + Interpreter Core, - None
resolution: not a bug
stage: resolved
2011-04-15 19:52:12belopolskysetassignee: belopolsky

messages: + msg133869
nosy: + belopolsky
2011-04-15 18:24:04jceasetnosy: + jcea
messages: + msg133861
2011-04-15 17:05:00eric.araujosetnosy: + eric.araujo
2011-04-15 14:45:34pasma10@concepts.nlsetmessages: + msg133828
2011-04-15 14:10:26vstinnersetnosy: + vstinner
2011-04-15 13:44:58nadeem.vawdasetnosy: + nadeem.vawda
messages: + msg133821
2011-04-15 13:41:26pasma10@concepts.nlcreate