IDEA: do not alter default SIGINT handling

On startup, the Python interpreter changes the default behavior of SIGINT, which results in many Python programs to ignore the keyboard interrupt exactly in the situations when users are most likely to use it (i.e.: when the program becomes unresponsive). Minimal testcase: $ echo "void foo() { for(;;) {} }" >foo.c $ gcc -shared -o foo.so foo.c $ python -c 'import ctypes;ctypes.CDLL("./foo.so").foo()' ^C^C^C ^C ^C DAMN! ^C This scenario mimics a Python program calling some blocking library function. It can also happen with IO-bound functions if they loop on read() and don't abort on short reads. One might be tempted to say "this behavior of the Python intepreter is by design" and suggest users to use CTRL-\ instead of CTRL-C. However, this non-standard behavior is very annoying for users who expect ^C to work on UNIX systems. In fact, no other compiled or interpreted language I know of behaves this way, and Python should not be the only exception. While I see the usefulness of KeyboardInterrupt from the programmer point of view, only a minority of programs actually need to trap SIGINT and do something with it. Other language runtimes require the programmer to manually trap SIGINT when needed. The Python interpreter could maintain backwards compatibility by enabling automatic SIGINT trapping when entering a "try" block that would intercept KeyboardInterrupt. For 2 years, I've been using this workaround in my /usr/lib64/python2.6/sitecustomize.py: ----cut----- import signal signal.signal(signal.SIGINT, signal.SIG_DFL) ----cut----- CTRL-C has been working perfectly ever since. So far, I have not yet found a single Python program where restoring the default behavior of SIGINT causes real issues, but there may certainly be a few. Granted, this is just a kludge, not a perfect fix, but from a user perspective, it already improves upon the current behavior (i.e. more pros than cons). At least, this is my personal experience. If you're skeptical, please try the above workaround yourself for a few months and let me know what breaks for you. If we could break the syntax of "print" statements, I'm sure we can also find a satisfactory compromise for CTRL-C handling that won't affect more than 0.1% of existing Python programs. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/

On Sun, Sep 13, 2009 at 2:25 PM, Bernie Innocenti <bernie@codewiz.org> wrote: <snip>
What does the print syntax have to do with this? You know it became a regular function in Python 3, right? Cheers, Chris -- http://blog.rebertia.com

El Sun, 13-09-2009 a las 14:32 -0700, Chris Rebert escribió:
Yes, I do. What I meant is that changing the behavior of SIGINT would introduce negligible incompatibilities compared to the things that were changed in Python 3.0. By this, I'm not implying that SIGINT handling must absolutely be changed NOW. It can certainly wait until the next major revision of the language, if one is planned. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/

On Sun, 13 Sep 2009 21:35:56 +0000 (UTC) Benjamin Peterson <benjamin@python.org> wrote:
They aren't now. os._exit() skips unwinding the try/except chain before exiting. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Mike Meyer wrote:
An application calling an underscore prefixed function (in the os module no less) is significantly different to a user pressing Ctrl-C while the application is running normally. If a user wants to kill it ungracefully, that's what Ctrl-Break is for. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

Nick Coghlan writes:
If a user wants to kill it ungracefully, that's what Ctrl-Break is for.
Discussion of how to spell SIGKILL looks like bikeshed painting to me, but the question of how to extend graceful interrupt behavior to C modules looks worthy of an idea to me. Is that too hard or too rare a need?

Stephen J. Turnbull wrote:
If someone can come up with an adequate C API spelling of the change (e.g. a PYTHON_BEGIN_ALLOW_SIGINT_ABORT/PYTHON_END_ALLOW_SIGINT_ABORT) and define it in such a way that the burden for cleaning up before resumption of execution of Python code is placed on the developer using the new API then I'd be +1. For a C API spelling with the semantics of a genuine C abort for the duration, I'd probably be -0 at best. I like Ctrl-C hitting exception handlers and finally clauses. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

Nick Coghlan schrieb:
Do you think people would use it? It's already hard to convince them of using the thread state macros correctly, and the benefit of doing that is subjectively much larger (multithreading works without blocking) than for the SIGINT handling. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

Georg Brandl wrote:
I think some of the major well-maintained extensions might be persuaded to use it (think numpy) and we'd be able to use it ourselves (time.sleep(), I'm looking at you). time.sleep() is actually a great example. Firstly, I didn't use it just yesterday precisely because dropping it in in a naive fashion would have broken Ctrl-C handling and I didn't feel like taking the time to use it in a less naive way. Secondly, it's a stateless call - if the sleep call is aborted due to a Ctrl-C, then the only thing to do before going back into Python code is reacquire the GIL. That said, my signal-handling-fu isn't even close to being able to handle writing the macros to make that happen. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

On Sep 14, 8:13 pm, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote:
It's OS-dependent, apparently. Ctrl-C interrupts for me too on Linux or in Cygwin, but it doesn't work on Windows XP. I sometimes replace sleep() with my own implementation that does small time.sleep()'s in a loop so that it can be interrupted.

[Greg]
What do you mean? Ctrl-C interrupts time.sleep() okay in my Python (on MacOSX).
[ryles]
it doesn't work on Windows XP.
It is, indeed, Windows. (I didn't realise the *nix based OS's didn't have this problem - an artifact of mostly using Python on Windows, despite the fact that I do my development *of* Python on Linux). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

Nick Coghlan schrieb:
But looking at timemodule.c, there's lots of code that says it's there for "Ctrl+C" events/interruptions on Windows. Did that work at any time? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

On Tue, Sep 15, 2009 at 02:55:03PM +0200, Georg Brandl wrote:
Works for me: C:\Python25>python.exe Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
WinXP SP2. Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.

Georg Brandl wrote:
Actually, it looks like it works with a modern version of Python (I just checked with the 2.6 install on my home Windows machine). My work environment is stuck on 2.4, which is comparatively ancient these days - it would appear someone fixed this particular gripe while I wasn't looking :) I guess that means we can scratch that as an example use case then... Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

On Sep 15, 9:34 am, Nick Coghlan <ncogh...@gmail.com> wrote:
Actually, it looks like it works with a modern version of Python (I just checked with the 2.6 install on my home Windows machine).
I'm using 2.6.2 on XP SP3 and time.sleep() is not interrupted with Control-C. FYI, threading.Event().wait(n) actually looks to be interruptible on both *nix and Windows.

On Tue, 15 Sep 2009 09:16:27 -0700 (PDT) ryles <rylesny@gmail.com> wrote:
Is there an example in the standard library that doesn't handle interrupts properly on both systems? How about a libc function that fails when invoked via ctypes? If not, then it might be reasonable to conclude that the problem is buggy extensions, and go back to figuring out how to make it easier to write extensions that handle this properly. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

On Sep 15, 3:45 pm, Mike Meyer <mwm-keyword-python.b4b...@mired.org> wrote:
Is there an example in the standard library that doesn't handle interrupts properly on both systems?
The one that often annoys people in the standard library is threading.Thread.join(): http://bugs.python.org/issue1167930

On Tue, Sep 15, 2009 at 4:31 PM, ryles <rylesny@gmail.com> wrote:
Another work around is to do absolutely nothing in your main program thread other than sit in: while not_time_to_exit: time.sleep(9999999) The main thread handles all signals. Move the rest of your work (including joining, etc) to other threads. Have one of them set not_time_to_exit and send a signal to yourself to cause the sleep to exit. (or instead of sleep, open a pipe and poke the pipe by writing some data to it to indicate its time to exit vs loop again, etc.)

ryles wrote:
Win32XP, Py3.1 Keyboard Interrupt is immediately caught in console. In IDLE, only caught when sleep ends.
while 1:pass
Traceback (most recent call last): File "<pyshell#12>", line 1, in <module> while 1:pass KeyboardInterrupt caught immediately even with idle.

On Mon, 14 Sep 2009 00:53:22 +0100 MRAB <python@mrabarnett.plus.com> wrote:
Possibly that will work on Windows. It won't work on Posix-compliant systems. The tty driver handles turning characters into signals to the controlling process, and does this in the kernel. To get a keystroke to generate some signal, you have to chose a signal the TTY driver can generate. Further, you need to use one that's not already used for other things. Needing to emulate SIGINFO on a system that doesn't support it, I wind up choosing SIGQUIT, as we don't get much use from python core dumps from production, whereas everything else I can't see the users giving up readily. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

MRAB writes:
How about 2 (or 3?) in rapid succession ("here's a CTRL-C, and here's another one to show I mean it!" :-)).
That's more complexity than you want to put in a signal handler. The way Emacs handles this is that the signal handler just enqueues a quit event, and the event loop checks for it and handles it. In other places (such as looping functions) more complex QUIT processing (that checks for repeated signals and throws to the innermost QUIT catcher) is done, but this can only be done in "safe" places, not in the signal handler itself. I imagine Python works the same way and it works fine in pure Python programs, too. The problem here is that when you return from the signal handler, you're trapped inside a poorly-written (for this purpose) C extension, and Python never gets to check for the first quit, let alone repeated ones. In Emacs it's pretty rare to get those, because Emacs is quite hostile to third-party C extensions, so C code QUIT-ified by the maintainers before it's allowed to be added. Python has lots of C extensions, and some are going to need QUIT occasionally -- but not often enough for the extension maintainer to notice and handle it. :-P

On Mon, 14 Sep 2009 10:23:14 +0900, Stephen J. Turnbull wrote:
A cursory check over the signal handler shows the Python calls PyErr_SetNone(PyExc_KeyboardInterrupt) within the signal handler itself. Handling a double-Ctrl-C would be very trivial, would solve the OP problem, and would not declare all existing C/C++ code in the world as "non-compatible-with-Python-ctrl-c-by-default", which is the current shame we live in. -- Giovanni Bajo Develer S.r.l. http://www.develer.com

MRAB schrieb:
Isn't it as easy as signal.signal(signal.SIGINT, signal.SIG_DFL) if you don't like the current handler? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

Georg Brandl schrieb:
I'm sorry, this was actually in the OP. Hopefully our diversity statement will include the reading-impaired :) Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

On Mon, 14 Sep 2009 07:35:56 am Benjamin Peterson wrote:
Guarantee not a guarantee :) Finally statements are only guaranteed to execute if the Python process isn't killed or otherwise interrupted. You can kill an unresponsive Python program from the outside, (say) with ctrl-\, and the finally clause never executes:
I think it's worth considering what the OP's real complaint is: namely, that (some? all?) C extensions can't be interrupted by ctrl-C as the user would expect. Is that a valid issue, or is it expected that Python has no control over what happens inside the C extension? -- Steven D'Aprano

Steven D'Aprano wrote:
You can kill an unresponsive Python program from the outside, (say) with ctrl-\, and the finally clause never executes:
Yes, but you expect that signal to kill the process immediately without bothering with any cleanup. Ctrl-C, on the other hand, is meant to be a graceful request to terminate cleanly. In the context of Python, one can reasonably expect that to include execution of finally blocks. -- Greg

Steven D'Aprano wrote:
I think it's an unavoidable consequence of the desire to be able to unwind cleanly in the event of a Ctrl-C. If it happens in the middle of arbitrary C code, you can't just jump out of it because that could leave things in an unpredictable state, and execution of further Python code wouldn't be safe. -- Greg

On Mon, 14 Sep 2009 10:16:21 +1000 Steven D'Aprano <steve@pearwood.info> wrote:
I think it's valid. It's expected that the USER will have some control over what's going on in a program - in particular, that they should be able to interrupt it pretty much any time barring a bug of some sort. The interaction between Python's default SIGINT handling and C extensions breaks that expectation. It's not clear what a good solution would be, though. This problem exists for pretty much all signal handlers - they don't get a chance to run if there's a misbehaving C extension executing. The simplest solution is to just not handle SIGINT by default, which raises the objection that try/finally doesn't "work". I don't think this will matter in most cases; the finally block is usually freeing up some resource that is going to be freed by the process exiting as part of default SIGINT behavior. We've certainly had similarly subtle changes that are much harder to deal with in the 2.X line. To me, the nasty part of such a change is the loss of traceback on SIGINT by default. During development, hitting C-C when the python code is in an infinite loop pretty reliably provides a traceback that nails down the problem. Yes, I could just boilerplate that into every program, but part of python's attraction is that such things are so seldom needed. I suspect this might be best dealt with by documenting how C extensions should behave with respect to signals - particularly SIGINT - and providing sample code for doing so. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Benjamin Peterson writes:
It would actually be a huge compatibility break because finally statments would no longer be garunteed to execute.
Hey, kill -9 trumps any guarantee you can give, and that's what the user resorts to in the use case at hand. This is a bad thing, even from the point of view of those who use "finally" a lot.

On Sun, Sep 13, 2009 at 2:25 PM, Bernie Innocenti <bernie@codewiz.org> wrote: <snip>
What does the print syntax have to do with this? You know it became a regular function in Python 3, right? Cheers, Chris -- http://blog.rebertia.com

El Sun, 13-09-2009 a las 14:32 -0700, Chris Rebert escribió:
Yes, I do. What I meant is that changing the behavior of SIGINT would introduce negligible incompatibilities compared to the things that were changed in Python 3.0. By this, I'm not implying that SIGINT handling must absolutely be changed NOW. It can certainly wait until the next major revision of the language, if one is planned. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/

On Sun, 13 Sep 2009 21:35:56 +0000 (UTC) Benjamin Peterson <benjamin@python.org> wrote:
They aren't now. os._exit() skips unwinding the try/except chain before exiting. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Mike Meyer wrote:
An application calling an underscore prefixed function (in the os module no less) is significantly different to a user pressing Ctrl-C while the application is running normally. If a user wants to kill it ungracefully, that's what Ctrl-Break is for. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

Nick Coghlan writes:
If a user wants to kill it ungracefully, that's what Ctrl-Break is for.
Discussion of how to spell SIGKILL looks like bikeshed painting to me, but the question of how to extend graceful interrupt behavior to C modules looks worthy of an idea to me. Is that too hard or too rare a need?

Stephen J. Turnbull wrote:
If someone can come up with an adequate C API spelling of the change (e.g. a PYTHON_BEGIN_ALLOW_SIGINT_ABORT/PYTHON_END_ALLOW_SIGINT_ABORT) and define it in such a way that the burden for cleaning up before resumption of execution of Python code is placed on the developer using the new API then I'd be +1. For a C API spelling with the semantics of a genuine C abort for the duration, I'd probably be -0 at best. I like Ctrl-C hitting exception handlers and finally clauses. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

Nick Coghlan schrieb:
Do you think people would use it? It's already hard to convince them of using the thread state macros correctly, and the benefit of doing that is subjectively much larger (multithreading works without blocking) than for the SIGINT handling. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

Georg Brandl wrote:
I think some of the major well-maintained extensions might be persuaded to use it (think numpy) and we'd be able to use it ourselves (time.sleep(), I'm looking at you). time.sleep() is actually a great example. Firstly, I didn't use it just yesterday precisely because dropping it in in a naive fashion would have broken Ctrl-C handling and I didn't feel like taking the time to use it in a less naive way. Secondly, it's a stateless call - if the sleep call is aborted due to a Ctrl-C, then the only thing to do before going back into Python code is reacquire the GIL. That said, my signal-handling-fu isn't even close to being able to handle writing the macros to make that happen. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

On Sep 14, 8:13 pm, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote:
It's OS-dependent, apparently. Ctrl-C interrupts for me too on Linux or in Cygwin, but it doesn't work on Windows XP. I sometimes replace sleep() with my own implementation that does small time.sleep()'s in a loop so that it can be interrupted.

[Greg]
What do you mean? Ctrl-C interrupts time.sleep() okay in my Python (on MacOSX).
[ryles]
it doesn't work on Windows XP.
It is, indeed, Windows. (I didn't realise the *nix based OS's didn't have this problem - an artifact of mostly using Python on Windows, despite the fact that I do my development *of* Python on Linux). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

Nick Coghlan schrieb:
But looking at timemodule.c, there's lots of code that says it's there for "Ctrl+C" events/interruptions on Windows. Did that work at any time? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

On Tue, Sep 15, 2009 at 02:55:03PM +0200, Georg Brandl wrote:
Works for me: C:\Python25>python.exe Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
WinXP SP2. Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.

Georg Brandl wrote:
Actually, it looks like it works with a modern version of Python (I just checked with the 2.6 install on my home Windows machine). My work environment is stuck on 2.4, which is comparatively ancient these days - it would appear someone fixed this particular gripe while I wasn't looking :) I guess that means we can scratch that as an example use case then... Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

On Sep 15, 9:34 am, Nick Coghlan <ncogh...@gmail.com> wrote:
Actually, it looks like it works with a modern version of Python (I just checked with the 2.6 install on my home Windows machine).
I'm using 2.6.2 on XP SP3 and time.sleep() is not interrupted with Control-C. FYI, threading.Event().wait(n) actually looks to be interruptible on both *nix and Windows.

On Tue, 15 Sep 2009 09:16:27 -0700 (PDT) ryles <rylesny@gmail.com> wrote:
Is there an example in the standard library that doesn't handle interrupts properly on both systems? How about a libc function that fails when invoked via ctypes? If not, then it might be reasonable to conclude that the problem is buggy extensions, and go back to figuring out how to make it easier to write extensions that handle this properly. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

On Sep 15, 3:45 pm, Mike Meyer <mwm-keyword-python.b4b...@mired.org> wrote:
Is there an example in the standard library that doesn't handle interrupts properly on both systems?
The one that often annoys people in the standard library is threading.Thread.join(): http://bugs.python.org/issue1167930

On Tue, Sep 15, 2009 at 4:31 PM, ryles <rylesny@gmail.com> wrote:
Another work around is to do absolutely nothing in your main program thread other than sit in: while not_time_to_exit: time.sleep(9999999) The main thread handles all signals. Move the rest of your work (including joining, etc) to other threads. Have one of them set not_time_to_exit and send a signal to yourself to cause the sleep to exit. (or instead of sleep, open a pipe and poke the pipe by writing some data to it to indicate its time to exit vs loop again, etc.)

ryles wrote:
Win32XP, Py3.1 Keyboard Interrupt is immediately caught in console. In IDLE, only caught when sleep ends.
while 1:pass
Traceback (most recent call last): File "<pyshell#12>", line 1, in <module> while 1:pass KeyboardInterrupt caught immediately even with idle.

On Mon, 14 Sep 2009 00:53:22 +0100 MRAB <python@mrabarnett.plus.com> wrote:
Possibly that will work on Windows. It won't work on Posix-compliant systems. The tty driver handles turning characters into signals to the controlling process, and does this in the kernel. To get a keystroke to generate some signal, you have to chose a signal the TTY driver can generate. Further, you need to use one that's not already used for other things. Needing to emulate SIGINFO on a system that doesn't support it, I wind up choosing SIGQUIT, as we don't get much use from python core dumps from production, whereas everything else I can't see the users giving up readily. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

MRAB writes:
How about 2 (or 3?) in rapid succession ("here's a CTRL-C, and here's another one to show I mean it!" :-)).
That's more complexity than you want to put in a signal handler. The way Emacs handles this is that the signal handler just enqueues a quit event, and the event loop checks for it and handles it. In other places (such as looping functions) more complex QUIT processing (that checks for repeated signals and throws to the innermost QUIT catcher) is done, but this can only be done in "safe" places, not in the signal handler itself. I imagine Python works the same way and it works fine in pure Python programs, too. The problem here is that when you return from the signal handler, you're trapped inside a poorly-written (for this purpose) C extension, and Python never gets to check for the first quit, let alone repeated ones. In Emacs it's pretty rare to get those, because Emacs is quite hostile to third-party C extensions, so C code QUIT-ified by the maintainers before it's allowed to be added. Python has lots of C extensions, and some are going to need QUIT occasionally -- but not often enough for the extension maintainer to notice and handle it. :-P

On Mon, 14 Sep 2009 10:23:14 +0900, Stephen J. Turnbull wrote:
A cursory check over the signal handler shows the Python calls PyErr_SetNone(PyExc_KeyboardInterrupt) within the signal handler itself. Handling a double-Ctrl-C would be very trivial, would solve the OP problem, and would not declare all existing C/C++ code in the world as "non-compatible-with-Python-ctrl-c-by-default", which is the current shame we live in. -- Giovanni Bajo Develer S.r.l. http://www.develer.com

MRAB schrieb:
Isn't it as easy as signal.signal(signal.SIGINT, signal.SIG_DFL) if you don't like the current handler? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

Georg Brandl schrieb:
I'm sorry, this was actually in the OP. Hopefully our diversity statement will include the reading-impaired :) Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

On Mon, 14 Sep 2009 07:35:56 am Benjamin Peterson wrote:
Guarantee not a guarantee :) Finally statements are only guaranteed to execute if the Python process isn't killed or otherwise interrupted. You can kill an unresponsive Python program from the outside, (say) with ctrl-\, and the finally clause never executes:
I think it's worth considering what the OP's real complaint is: namely, that (some? all?) C extensions can't be interrupted by ctrl-C as the user would expect. Is that a valid issue, or is it expected that Python has no control over what happens inside the C extension? -- Steven D'Aprano

Steven D'Aprano wrote:
You can kill an unresponsive Python program from the outside, (say) with ctrl-\, and the finally clause never executes:
Yes, but you expect that signal to kill the process immediately without bothering with any cleanup. Ctrl-C, on the other hand, is meant to be a graceful request to terminate cleanly. In the context of Python, one can reasonably expect that to include execution of finally blocks. -- Greg
participants (16)
-
Benjamin Peterson
-
Bernie Innocenti
-
Chris Rebert
-
Georg Brandl
-
Giovanni Bajo
-
Greg Ewing
-
Gregory P. Smith
-
Mike Meyer
-
MRAB
-
Nick Coghlan
-
Oleg Broytmann
-
Paul Moore
-
ryles
-
Stephen J. Turnbull
-
Steven D'Aprano
-
Terry Reedy