[issue6901] Runaway programs often become unresponsive to CTRL-C
New submission from Bernie H. Innocenti :
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.
--
components: Interpreter Core
messages: 92576
nosy: bernie
severity: normal
status: open
title: Runaway programs often become unresponsive to CTRL-C
versions: Python 2.6, Python 3.0
___
Python tracker
<http://bugs.python.org/issue6901>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6901] Runaway programs often become unresponsive to CTRL-C
Bernie H. Innocenti added the comment: > This is a fundemental behavior that will never change. If you > dislike it, you can remove the signal handler for it with the > signal module. What? We could break the syntax of "print" statements and cannot change this minor detail that afftects many 1% of all Python programs? As a matter of fact, for 2 years I've been using this in my /usr/lib64/python2.6/sitecustomize.py: cut- import signal signal.signal(signal.SIGINT, signal.SIG_DFL) cut- ^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 this workaround yourself for a few months and let me know what breaks for you. -- ___ Python tracker <http://bugs.python.org/issue6901> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6901] Runaway programs often become unresponsive to CTRL-C
Bernie H. Innocenti added the comment: Ok -- ___ Python tracker <http://bugs.python.org/issue6901> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2504] Add gettext.pgettext() and variants support
Bernie H. Innocenti added the comment: While we're waiting for this patch to be upstreamed, what's the best way to emulate this functionality with the current gettext module? I'm looking at the patch and it seems that code similar to this might work? def pgettext(ctx, msg): return gettext(ctx + "\x04" + msg) -- nosy: +bernie ___ Python tracker <http://bugs.python.org/issue2504> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
