The attached script runs a long processing loop.

Start it in IDLE. Open the script and run it.

Press control-C. Result: message, KeyboardInterrupt with traceback message.

In shell window, turn on Debugger. Run the script.

Press control-C. Result: Restrat message shown in Python Shell. Debug Control shows no change.

Expected behavior: For keyboard interrupt, or for any uncaught exception, Debug Control should show the same information as if there was a breakpoint. For instance, the stack with line numbers, locals and globals.

Better: make a way to interrupt the program in a long loop or process, so that the programmer can tell -- live -- where the program is, and where most of the time is being used. Then use the regular buttons, Go, etc. to continue the process, possibly interrupted again.

Also: the IDLE Python Shell and Debug Control show no "running" indicator, so there is no easy way to tell if the program is still going.

I can confirm the issue Larry's raises. Attached is a patch against 2.7 to enable Ctrl+C interrupts for the debugger. The patch opens up the possibility of making "Go" a toggle button, but that would require some more plumbing (not included in patch).

A "run" indicator should be simple to implement. The status bar can contain a label that can be updated with calls to "beginexecuting" and "endexecuting" in PyShell.py.

'raise KeyboardInterrupt' in code causes shell to hang until Restart Shell Cntl-F6 in invoked.

>>> 
[DEBUG ON]
>>> raise KeyboardInterrupt
<debug window activates.  Hit [step].  Window deactivates.  No prompt, even in response to Enter.  Shell unresponsive.>
<Restart Shell>
=============================== RESTART: Shell ===============================
[DEBUG ON]
>>> 

The behavior was noted by pperry on #26949, which is about SystemExit behavior.  I currently think it part of this issue.

More info: Even though the debug window looks inactive, it is not.  After the restart, debugger cannot be turned off because it is 'active'.  It must be stuck on the raise statement.  The window can be closed, but after that, it cannot be brought back because something is still going.  It takes another Restart to restart debugger.

The reproduce step can be reduce to:

1. open idlelib with debugger (./python -m idlelib -d)
2. enter print() (or any other function call)
3. Control-C breakout

Then it will restart the shell.

Update roger's patch to current version.

Is there any reason this patch isn't merged? The problem in #26949 is a separate issue about this problem.

Roger, will you convert the patch to GitHub PR? The patch runs will, there are only two point need to add: 

  1. user_interrupt should clear sys.settrace when step in
  2. cancel_callback add a interp.write("\nKeyboardInterrupt\n")

Thanks.

Roger, Python development has moved from hg and out private server to git and GitHub.  Patches posted on the tracker must be converted to git pull requests (PRs) to be merged, and also for proper review and editing.  Unless you prefer to do it yourself, we will.  The only difference is the 'author' field of the PR.  Credit in the commit message and news entry remains as it was.

Louie, make a PR for this any time you want to.  I do not expect a quick response either way.  The original commit should be the patch as is other than necessary updates for 3.7, and identified as Roger's in the commit message.  Then make your changes in separate commits.

The patch is upload to PR 1821, if Roger get a GitHub account and linked to b.p.o, we can rebase the first commit and change the author in commit message to Roger's account information.

Mark, since you are working on redoing the debugger gui, do you have any opinion on this?  The basic idea is that ^C when debugging should just interrupt the remote process, not end it, just as when there is no debugger.  I agree.

I just updated the PR to current master but have not at the moment tested it.

Terry, I agree that Ctrl-C should act just as an interrupt when the debugger is active. I also agree that a way to interrupt the debugger through the user interface is needed (in the revised UI, there's an explicit 'stop' button for that).