| msg133821 - (view) |
Author: Nadeem Vawda (nadeem.vawda) *  |
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 (pasma10@concepts.nl) |
Date: 2011-04-15 14:45 |
| Hello, 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 "", line 1, in 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) * |
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) * |
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 "", line 1, in IOError: [Errno 9] Bad file descriptor I'll look further. |
|
|
| msg133871 - (view) |
Author: Alexander Belopolsky (belopolsky) * |
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. [1] http://pubs.opengroup.org/onlinepubs/009695399/functions/fflush.html |
|
|
| msg133874 - (view) |
Author: Terry J. Reedy (terry.reedy) * |
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 (pasma10@concepts.nl) |
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: http://code.google.com/p/apsw/issues/detail?id=117 |
|
|
| msg133883 - (view) |
Author: Ned Deily (ned.deily) * |
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. |
|
|