There seems to be an issue capturing keyboard interrupts on Windows 10 when using raw_input() inside of a class method w/python 2.7.x.

So far I have tested this on:
2.7.11 x86 on Windows 10 x64 - Does not capture (Traceback)
2.7.11 x64 on Windows 10 x64 - Does not capture (Traceback)
2.7.11 x86 on Windows XP - Does capture

So far I've only tested 2.7.11, so I don't know which other version may or may not be affected. The proof of concept code is attached.

If there is anything else I can provide to help, please let me know. I'm not accustomed to posting bugs here so I apologize if I've missed something.

I don't have Win10 to test with, but can you confirm that the method is
necessary for the code to fail? IOW does this fail equally?

while True:
    try: raw_input()
    except KeyboardInterrupt: print "Interrupt!"

Also, do I assume that the code simply carries on regardless without
reaching the exception handler? Or does something else happen?

Please try Python 3, I recall that we fixed bugs on input() on Windows related to CTRL+c.

Hi,

Thanks for the quick response.

I tried your code, it doesn't capture the keyboard interrupt, so the method doesn't seem to be needed. Also, the code doesn't carry on if interrupt was received, but instead produces the stack traceback. For example:

while True:
    try:
        data = raw_input()
        print data
    except KeyboardInterrupt:
        print "Interrupt!"
    
Does not print "data" if a KeyboardInterrupt is received during raw_input.

Unfortunately, I can't use python 3 as my organization currently uses 2 in their production environment.

If I run your code, it does what I expect: pressing Ctrl-C produces
"Interrupt", doesn't print the data returned from raw_input, and doesn't
produce a stacktrace.

I'm not on Win10 and it's entirely possible that this area of the MS CRT
has been reworked: it's a bit quirky and our use of it is fairly fragile.

I'm still not clear, though, whether we have a bug or whether it's just
that your expectation is at odds with the way in which this is intended
to work.

If you think there's a bug here, could you run the code you posted in a
console window, do what actions are needed to make it fail, and then
cut-and-paste the result here, possibly as an attached file. (Don't post
a screenshot; just use the cmd window's mark-and-copy functionality to
select the visible text).

I can reproduce on Windows 10 with Pythons 2.7.11, 3.4.4, and 3.5.1 with the attached script. Examples:

E:\>ver

Microsoft Windows [Version 10.0.10586]

E:\>py ccbug.py
2.7.11 (v2.7.11:6d1b6a68f775, Dec  5 2015, 20:32:19) [MSC v.1500 32 bit (Intel)]
Traceback (most recent call last):
  File "ccbug.py", line 12, in <module>
    data = input()


E:\>py -3.4 ccbug.py
3.4.4 (v3.4.4:737efcadf5a6, Dec 20 2015, 19:28:18) [MSC v.1600 32 bit (Intel)]
Traceback (most recent call last):
  File "ccbug.py", line 12, in <module>

E:\>py -3.5 ccbug.py
3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:54:25) [MSC v.1900 64 bit (AMD64)]
Traceback (most recent call last):
  File "ccbug.py", line 12, in <module>

I can post a script if necessary, but it looks like Zach has already done so. I appreciate you verifying this.

It sounds like you guys might be (re-)discovering existing bugs to do with KeyboardInterrupt in input on Windows:

• bpo-18597 (Py 2 & 3): Strange exception handling reading stdin
• bpo-10837 (2.7): KeyboardInterrupt deferred reading stdin
• bpo-25376 (Py 3): Truncated traceback from input()
• bpo-13673 (Py 2 & 3): General traceback truncated if interrupted

Yeah, so this looks like a behavior in Windows in which an EOFError is raised when a Ctrl + C is pressed, followed by a KeyboardInterrupt.

This post basically explains how to overcome it: http://stackoverflow.com/questions/31127652/cannot-catch-keyboardinterrupt-in-command-prompt-twice

def bing():
    try:
        input()
    except EOFError:
        print("Caught an EOFError")

try:
bing()
print("After bing")
except KeyboardInterrupt:
print("Final KeyboardInterrupt")

Sorry for necro-ing an old issue.