[issue26351] Occasionally check for Ctrl-C in long-running operations like sum

Trey Hunner added the comment: This is a problem I experience occasionally while teaching and while developing teaching curriculum. I tend to close problem windows quickly enough to avoid a computer crash in front of a live audience, but it's still an annoyance to get the REPL state back to

[issue26351] Occasionally check for Ctrl-C in long-running operations like sum

STINNER Victor added the comment: You should try https://github.com/python/performance to get reliable benchmark results ;-) -- ___ Python tracker ___

[issue26351] Occasionally check for Ctrl-C in long-running operations like sum

Nick Coghlan added the comment: George's initial patch that naively checks for signals on every iteration could be used to get an upper bound on the likely benchmark impact. I do think this is a case where we'll want a dedicated microbenchmark to complement the macrobenchmark suite, though -

[issue26351] Occasionally check for Ctrl-C in long-running operations like sum

Terry J. Reedy added the comment: The request is to check 'occasionally'. To me this means perhaps once a second, which is to say, ^c should generally interrupt within a second, and on average with half a second. The following takes just under a second: "sum(i for i in range(1000))"

[issue26351] Occasionally check for Ctrl-C in long-running operations like sum

STINNER Victor added the comment: Can someone work on a patch? Then we can benchmark it to take a decision ;-) Maybe we might expose signalmodule.c internals to have a cheaper check? -- ___ Python tracker

[issue26351] Occasionally check for Ctrl-C in long-running operations like sum

Nick Coghlan added the comment: As far as the "What's the benefit to users?" question goes, I think the main intended beneficiaries would be children and other folks playing at the command prompt and trying out different things. The "no segfaults from normal Python code" rule aims to make

[issue26351] Occasionally check for Ctrl-C in long-running operations like sum

Nick Coghlan added the comment: While I agree with Raymond regarding the performance implications if this isn't handled carefully, I think we're also getting to a point where better accounting for signal handling latency in inner loops is something that could be considered for 3.7 - the

[issue26351] Occasionally check for Ctrl-C in long-running operations like sum

Raymond Hettinger added the comment: I think this needs more discussion on python-dev before going down this path. In reality, we have many places that have "long running" C code when fed extreme arguments. In practice, we almost never have a problem with these except for cute toy bug

[issue26351] Occasionally check for Ctrl-C in long-running operations like sum

George Slavin added the comment: I've attached the test for this patch (I couldn't figure out how to upload two files with one comment). -- Added file: http://bugs.python.org/file44747/test_sig_int_builtins.py ___ Python tracker

[issue26351] Occasionally check for Ctrl-C in long-running operations like sum

George Slavin added the comment: I have a patch that checks for KeyboardInterrupt during builtin operations. This allows sum, max, min, list, dict, set, and tuple calls to be interrupted when they are working on infinite iterators. I've attached the patch, and a test I wrote to show that you

[issue26351] Occasionally check for Ctrl-C in long-running operations like sum

Changes by wim glenn : -- nosy: +wim.glenn ___ Python tracker ___ ___ Python-bugs-list

[issue26351] Occasionally check for Ctrl-C in long-running operations like sum

Terry J. Reedy added the comment: I verified that ^Break(pause) works. It even causes ^C to be printed. -- ___ Python tracker ___

[issue26351] Occasionally check for Ctrl-C in long-running operations like sum

STINNER Victor added the comment: > Great idea. In Windows, closing the window with [x] will kill the process, > at the cost of loosing its contents. Note: after a few years, I heard that Windows supports something like SIGKILL: CTRL+Pause kills the current process ;-) You loose the process,

[issue26351] Occasionally check for Ctrl-C in long-running operations like sum

Terry J. Reedy added the comment: Great idea. In Windows, closing the window with [x] will kill the process, at the cost of loosing its contents. In IDLE's Shell, Restart Shell will do the same without killing IDLE, but it is easy to not know of or forget that option in a moment of panic.

[issue26351] Occasionally check for Ctrl-C in long-running operations like sum

Nick Coghlan added the comment: At least list() and potentially other container constructors are also affected. While it's mentioned in the thread, I'll explicitly note here that the problem is specifically with iterators implemented in C, like itertools.count(). Iterators implemented in

[issue26351] Occasionally check for Ctrl-C in long-running operations like sum

Changes by Serhiy Storchaka : -- nosy: +rhettinger ___ Python tracker ___ ___

[issue26351] Occasionally check for Ctrl-C in long-running operations like sum

Raymond Hettinger added the comment: FWIW, this doesn't seem to be solving any real life problems, only contrived examples. If any changes are made, they should be very restricted in scope, taking care to not wreck the performance of tools designed for speed and not to add useless crud to

[issue26351] Occasionally check for Ctrl-C in long-running operations like sum

Changes by Raymond Hettinger : -- Removed message: http://bugs.python.org/msg260255 ___ Python tracker ___

[issue26351] Occasionally check for Ctrl-C in long-running operations like sum

New submission from Steven D'Aprano: There are a few operations such as summing or unpacking infinite iterators where the interpreter can become unresponsive and ignore Ctrl-C KeyboardInterrupt. Guido suggests that such places should occasionally check for signals:

[issue26351] Occasionally check for Ctrl-C in long-running operations like sum

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___