Pressing Ctrl+C to raise a KeyboardInterrupt while waiting for user input in an input() call yields an incomplete traceback.

The behaviour appears in a Python REPL session started by issuing "python" without quotes in a Windows cmd session:

Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> input("Question: ")
Question: Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
>>>

When executing input_test.py (a single line Python source code file containing just an input("Question: ") call) from the cmd prompt by issuing "python input_test.py" without quotes, every other time the traceback is incomplete and every other time the Ctrl+C keypress yields, erroneously, an EOFError instead of a KeyboardInterrupt:

C:\x>python input_test.py
Question: Traceback (most recent call last):
  File "input_test.py", line 1, in <module>
    input("Question: ")
EOFError
^C
C:\x>python input_test.py
Question: Traceback (most recent call last):
  File "input_test.py", line 1, in <module>

C:\x>

Just tried the same in an IDLE session, but it seems to display the KeyboardInterrupt correctly:

Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37) [MSC v.1900 64 bit (AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> input("Question: ")
Question: 
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    input("Question: ")
  File "C:\y\Python\Python35\lib\idlelib\PyShell.py", line 1385, in readline
    line = self._line_buffer or self.shell.readline()
KeyboardInterrupt
>>> 

Running the file input_test.py I meantioned in my original report doesn't seem to diplay anything when Ctrl+C is pressed:

============= RESTART: C:\x\input_test.py =============
Question:

>>

Did some more testing. KeyboardInterrupt traceback displays properly when pressing Ctrl+C during an infinite loop:

Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> while True:
...     pass
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
KeyboardInterrupt
>>>

Also when running a file in a similar way as I did in the original bug report:

C:\x>python infinite_loop.py
Traceback (most recent call last):
  File "infinite_loop.py", line 2, in <module>
    pass
KeyboardInterrupt

C:\x>

Could this mean that the problem is more related to reading stdin than the actual KeyboardInterrupt?

Yes, this is probably a duplicate of bpo-18597.

I am no Windows expert, but I read in bpo-18597 that Ctrl+C is treated as EOF, except that a SIGINT is also sent in the background. This would explain why you see an EOFError. The partial traceback may also be from the same EOFError. Or both cases could be truncated reports of KeyboardInterrupt chained onto EOFError.

I understand the code path for input() may bypass the usual stdin.read() and readline() methods. bpo-18597 is about readline(), so it may not be an exact duplicate.

See also bpo-17619, which hints that KeyboardInterrupt handling for input() was worked on and fixed in 3.3. So why is it broken again in 3.4? A regression test would be nice, if at all possible. Does Windows have an equivalent of pseudo terminals?

Possibly also related is bpo-13673, about functions (like input) raising an exception (like EOFError), when SIGINT has been received. It mentions the interpreter completely failing to report the entire traceback, or truncating the traceback. It might be worth trying out the patch there. It might also be interesting to check sys.last_value in the interactive case.