You can clone with
As detailed on the user list (http://mail.scipy.org/pipermail/ipython-user/2012-October/011274.html) pressing Ctrl-C in ipdb will cause the QtConsole to hang. Tested on Windows 32bit Python with latest IPython.
One possible way to deal with this is to revert Ctrl-C to meaning 'copy' during the prompt for a raw_input() call. But there are also situations where you want to use Ctrl-C to break out of a loop of inputs.
Apologies, my emails to the user list have been getting bounced. Can continue the discussion here though.
I'm not sure exactly what you mean by breaking out of a loop of inputs? On the assumption that you meant breaking out of a raw_input() by pressing Ctrl-C I tried that and it also hangs the QtConsole in the same manner as pressing Ctrl-C in ipdb.
Oh, yes, the fact that it hangs rather than breaking is certainly a bug (although I can't replicate it on Linux, as I mentioned on the mailing list).
I was thinking of another comment you made, that you expect Ctrl-C to copy. We try to be smart about that, but obviously IPython isn't psychic.
I can see that there's conflicting requirements here and probably no perfect solution. From my own experience I think your suggestion of having Ctrl-C copy whilst at the prompt would be an improvement, but I'd be fine if it worked as on Linux, just kicking you out of the debug session.
If any of the IPython devs would like an Azure VM to test on I can probably sort one out - just let me know.
Thanks Dave. I think we can mostly get access to Windows to test on, but most of us don't use Windows day-to-day. @jstenar is often the one who does Windows fixes.
If you set something that's not an input prompt going (time.sleep(10)), can you interrupt it with Ctrl-C in the Qt console?
Ctrl-C doesn't interrupt time.sleep for me although it seems to keep the Ctrl-C in a buffer such that a KeyboardInterrupt is thrown immediately after time.sleep returns - i.e.
In : try:
...: print 'Entering sleep @', time.ctime()
...: time.sleep(15) # Pressed Ctrl-C here
...: print 'Exited sleep @', time.ctime()
...: except KeyboardInterrupt:
...: print 'KeyboardInterrupt raised @', time.ctime()
Entering sleep @ Mon Oct 08 20:40:02 2012
KeyboardInterrupt raised @ Mon Oct 08 20:40:17 2012
In the terminal Ctrl-C in the debugger will simply exit the debugging session and Ctrl-C in a time.sleep will immediately exit the sleep.
However Ctrl-C at any time, anywhere in the terminal IPython (on Windows) will kill the IPython session. By kill I mean that it will return you what looks like an IPython prompt but anything you type gets executed in the terminal rather than IPython before returning you back to an apparent IPython prompt - e.g.
In : try:
....: print 'Entering sleep @', time.ctime()
....: time.sleep(15) # Pressed Ctrl-C here
....: print 'Exited sleep @', time.ctime()
....: except KeyboardInterrupt:
....: print 'KeyboardInterrupt raised @', time.ctime()
Entering sleep @ Tue Oct 09 09:24:40 2012
KeyboardInterrupt raised @ Tue Oct 09 09:24:42 2012
In : x = 10
'x' is not recognized as an internal or external command,
operable program or batch file.
Ctrl-Break will immediately exit the terminal IPython session without prompting but has no effect in the QtConsole.
I wonder if that's the setuptools bug @jstenar mentioned. Can you try starting IPython using ipython-script.py? Also, how does Ctrl-C behave at a plain Python prompt (not IPython)?
Wow, that's nasty! I can confirm that when started with ipython-script.py the terminal IPython behaves as expected - i.e. Ctrl-C will drop you out of the debugger (to a working IPython prompt) and will interrupt a time.sleep call.
A plain python interpreter it behaves much as the terminal IPython i.e. it will break out of a time.sleep call and will also break out of the pdb debugger.
So it seems to just be an issue in the QtConsole.
I'm having this issue as well - in QT console windows. When I do post-mortem debugging, pressing ctrl+c hangs qt console. (IPython 13.2 with Anaconda 64bit in Windows 8)
@dhirschfeld @joonro is this still an issue in QtConsole? there's been no activity here for a while
Marking as needs-info so on a future pass (in a month?) we can close this if there's no activity