homepage

On Python 3.4, input() does not use wrapped sys.stdout. For example, the following script should print "Wrapped stdout" by print() and input() because sys.stdout is replaced with Writer object.
--------
import io
import sys
class Writer:
 def __getattr__(self, name):
 return getattr(sys.__stdout__, name)
 def write(self, data):
 if data != '\n':
 sys.__stdout__.write('Wrapped stdout\n')
 def fileno():
 raise OSError()
sys.stdout = Writer()
print('print')
input('input')
------
But the script does not print "Wrapped stdout" as prompt of input(). The script
prints the following.
-----
Wrapped stdout
input
----
Although, when sys.stdin is also wrapped, input() will use sys.stdout for prompt. For example, the following script prints "Wrapped stdout" by print() and input().
----
import io
import sys
class Writer:
 def __getattr__(self, name):
 return getattr(sys.__stdout__, name)
 def write(self, data):
 if data != '\n':
 sys.__stdout__.write('Wrapped stdout\n')
 def fileno():
 raise OSError()
class Reader:
 def __getattr__(self, name):
 return getattr(sys.__stdin__, name)
 def read(self, size):
 return sys.__stdin__.read(size)
 def fileno():
 raise OSError()
sys.stdout = Writer()
sys.stdin = Reader()
print('print')
input('input')
----
The script prints the following.
-----
Wrapped stdout
Wrapped stdout
----

This looks like an oversight. In the implementation in [bltinmodule.c][1], if checking sys.stdout.fileno() fails, it clears the error without setting tty = 0. It's the [same in 3.5][2].
 /* We should only use (GNU) readline if Python's sys.stdin and
 sys.stdout are the same as C's stdin and stdout, because we
 need to pass it those. */
 tmp = _PyObject_CallMethodId(fin, &PyId_fileno, "");
 if (tmp == NULL) {
 PyErr_Clear();
 tty = 0;
 }
 else {
 fd = PyLong_AsLong(tmp);
 Py_DECREF(tmp);
 if (fd < 0 && PyErr_Occurred())
 return NULL;
 tty = fd == fileno(stdin) && isatty(fd);
 }
 if (tty) {
 tmp = _PyObject_CallMethodId(fout, &PyId_fileno, "");
 if (tmp == NULL)
 PyErr_Clear();
 else {
 fd = PyLong_AsLong(tmp);
 Py_DECREF(tmp);
 if (fd < 0 && PyErr_Occurred())
 return NULL;
 tty = fd == fileno(stdout) && isatty(fd);
 }
 }
[1]: https://hg.python.org/cpython/file/b4cbecbc0781/Python/bltinmodule.c#l1709
[2]: https://hg.python.org/cpython/file/7a088af5615b/Python/bltinmodule.c#l1839 

Okay, so the change is straightforward. With this change the entire test suite passes on my machine.
We'll need a test for this for the test suite, and that's far less straightforward. It seems that test.test_builtin.BuiltinTest.check_input_tty() could be a starting point. Could someone come up with a working test for this?

Here's a patch with just the required fix (no tests).

Patch itself looks good.

This patch includes a test case using pty.fork() to ensure stdin is a terminal, so the bug would be triggered. It is a bit tricky, but hopefully works on Unix platforms. I have only tested it on Linux.

LGTM. See also minor note on Rietveld.
I think it is worth to extract all input() tests to separate class.

Okay I plan to commit a modified version where I moved the input() test methods that use pseudo terminals to a new PtyTests class. The test_input() method stays in the original class, because it shares a helper method with other tests.
I am resisting dropping that decode() step, because it makes any error message from the forked child hard to read:
AssertionError: 256 != 0 : b'quux\r\nTraceback (most recent call last):\r\n File "/media/disk/home/proj/python/cpython/Lib/test/test_builtin.py", line 1593, in test_input_no_stdout_fileno\r\n input("prompt")\r\nTypeError: bad argument type for built-in operation\r\n'

New changeset 425d81d10b13 by Martin Panter in branch '3.4':
Issue #24402: Fix input() when stdout.fileno() fails; diagnosed by Eryksun
https://hg.python.org/cpython/rev/425d81d10b13
New changeset e97d940a6543 by Martin Panter in branch '3.5':
Issue #24402: Merge input() fix from 3.4 into 3.5
https://hg.python.org/cpython/rev/e97d940a6543
New changeset bcc0f8eb6797 by Martin Panter in branch 'default':
Issue #24402: Merge input() fix from 3.5
https://hg.python.org/cpython/rev/bcc0f8eb6797 

Seems my test hangs the Free BSD 9 buildbot, although Free BSD 10 apparently passed.
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.4/builds/1128/steps/test/logs/stdio
[390/390] test_builtin
Timeout (1:00:00)!
Thread 0x0000000801407400 (most recent call first):
 File "/usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/test/test_builtin.py", line 1585 in test_input_no_stdout_fileno
 File "/usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/unittest/case.py", line 580 in run
 File "/usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/unittest/case.py", line 628 in __call__

This test also fails on Ubuntu.
[1/1] test_builtin
test test_builtin failed -- Traceback (most recent call last):
 File "/home/angwer/my-cpython/Lib/test/test_builtin.py", line 1588, in test_input_no_stdout_fileno
 self.assertEqual(status, 0, output)
AssertionError: 256 != 0 : quux
Traceback (most recent call last):
 File "/home/angwer/my-cpython/Lib/test/test_builtin.py", line 1593, in test_input_no_stdout_fileno
 input("prompt")
TypeError: bad argument type for built-in operation
1 test failed:
 test_builtin

I wrote this on Arch Linux, so I doubt your Ubuntu failure is valid. The error you see is what I would expect if the bug were not actually fixed. I suspect you need to recompile /Python/bltinmodule.c, which contains the bug fix.
However, the test also hangs OS X buildbots. I can only guess at why it is hanging, either at the waitpid() line or the os.read() line. I am looking at refactoring my test to use the existing check_input_tty() infrastructure. It seems over the top by adding a separate pipe back to the parent process, but presumably will workaround whatever is causing the hang.

It's my fault. I forget to recompile. Now it works.

New changeset d8dd9015b086 by Martin Panter in branch '3.4':
Issue #24402: Factor out PtyTests.run_child() in input() tests
https://hg.python.org/cpython/rev/d8dd9015b086
New changeset 6a8f96b46dce by Martin Panter in branch '3.5':
Issue #24402: Merge potential test fix from 3.4 into 3.5
https://hg.python.org/cpython/rev/6a8f96b46dce
New changeset cb574ee7231e by Martin Panter in branch 'default':
Issue #24402: Merge potential test fix from 3.5
https://hg.python.org/cpython/rev/cb574ee7231e 

My second attempt seems to have avoided the hang.
For the record, the backtrace from 3.4.koobs-freebsd9 did say it was hanging at the os.waitpid() line, but I still don’t understand why.