homepage

When I run a Python 3.3.4 prompt inside Emacs 24.3 on Windows 7, correct commands are evaluated immediately, but incorrect ones are delayed (I have to press Enter one more time), as seen below:
 >>> 1
 1
 >>> nonsense
 >>>
 Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 NameError: name 'nonsense' is not defined
Python 2 does not do this. I've filed an Emacs bug report (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17304) and got the response to try this on the command line (where cat.exe is from an MSYS installation):
 python 2>&1 | cat.exe
and it behaves the same way as in Emacs.

This can be reproduced as easily under Linux:
$ ./python 2>&1 | cat
Python 3.5.0a0 (default:17689e43839a+39f2a78f4357+, May 9 2014, 00:30:19) 
[GCC 4.8.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 5
5
>>> 1/0
>>> nonsense
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
ZeroDivisionError: division by zero
>>> 
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
NameError: name 'nonsense' is not defined
>>>

Attached patch fixes it under Linux, and adds tests.
I'd be glad if someone could give it a run under Windows.

The patch fixes `python 2>&1 | cat.exe` for me on Windows, where cat.exe is from GnuWin32. The tests also pass. It looks like failing would entail hanging until a timeout.

New changeset ab3e012c45d0 by Antoine Pitrou in branch '3.4':
Issue #21425: Fix flushing of standard streams in the interactive interpreter.
http://hg.python.org/cpython/rev/ab3e012c45d0
New changeset d1c0cf44160c by Antoine Pitrou in branch 'default':
Issue #21425: Fix flushing of standard streams in the interactive interpreter.
http://hg.python.org/cpython/rev/d1c0cf44160c 

Thanks for the report. This should now be fixed in 3.4 and 3.5.

Apparently the new tests hang on the "Fedora without threads" buildbot.
Stefan, could you take a look?
http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%203.4/builds/123 

Also on the PowerLinux buildbot:
http://buildbot.python.org/all/builders/PPC64%20PowerLinux%203.4/builds/113/ 

Judging by the faulthandler traceback in the PowerLinux build:
Timeout (1:00:00)!
Thread 0x0000008074e46670 (most recent call first):
 File "/home/shager/cpython-buildarea/3.4.edelsohn-powerlinux-ppc64/build/Lib/test/test_cmd_line_script.py", line 192 in interactive_python
 File "/home/shager/cpython-buildarea/3.4.edelsohn-powerlinux-ppc64/build/Lib/contextlib.py", line 59 in __enter__
 File "/home/shager/cpython-buildarea/3.4.edelsohn-powerlinux-ppc64/build/Lib/test/test_cmd_line_script.py", line 205 in check_repl_stderr_flush
 File "/home/shager/cpython-buildarea/3.4.edelsohn-powerlinux-ppc64/build/Lib/test/test_cmd_line_script.py", line 220 in test_repl_stderr_flush
[snip]
... the test is actually stuck trying to read the interactive prompt from stderr:
 # Drain stderr until prompt
 while True:
 data = stderr.read(4)
 if data == b">>> ":
 break
 stderr.readline() <-- HERE

New changeset ffae7aad9dfa by Antoine Pitrou in branch 'default':
Add debugging output for #21425
http://hg.python.org/cpython/rev/ffae7aad9dfa 

So, it seems like under Fedora (or PowerLinux), the Python interactive prompt produces different byte contents on stderr:
[ 21/389] test_cmd_line_script
repl stderr[:4]: b'Pyth'
repl stderr[:4]: b'[GCC'
repl stderr[:4]: b'Type'
repl stderr[:4]: b'\x1b[?1'
I wonder if it's because of GNU readline?

This looks like a well-known issue on Fedora (and Red Hat?):
http://stackoverflow.com/questions/15760712/python-readline-module-prints-escape-character-during-import
http://reinout.vanrees.org/weblog/2009/08/14/readline-invisible-character-hack.html
http://lists.gnu.org/archive/html/bug-readline/2007-08/msg00004.html
Apparently using XTERM=vt100 would workaround the issue.
(I can't reproduce under Ubuntu)

New changeset e57718ac8ff8 by Antoine Pitrou in branch 'default':
Try workaround for test issues in #21425
http://hg.python.org/cpython/rev/e57718ac8ff8 

According to https://bugzilla.redhat.com/show_bug.cgi?id=880393, this has actually been reported to us as issue19884.

Workarounds seem to work.

New changeset 58e2116576cf by Antoine Pitrou in branch '3.4':
Try workaround for test issues in #21425
http://hg.python.org/cpython/rev/58e2116576cf 

Workaround actually broke tests under shared library builds, because LD_LIBRARY_PATH isn't forwarded anymore. Will try another fix :-(

New changeset 5a1b2566d68e by Antoine Pitrou in branch 'default':
Try to fix issue #21425 workaround for shared library builds
http://hg.python.org/cpython/rev/5a1b2566d68e 

New changeset 974c0718c7e0 by Antoine Pitrou in branch '3.4':
Try to fix issue #21425 workaround for shared library builds
http://hg.python.org/cpython/rev/974c0718c7e0