Issue 1043446: Interpreter should be interruptable everywhere (original) (raw)

Logged In: YES user_id=80475

FWIW, there are many variations of this theme using almost anything accepting an iterable input (dict.fromkeys, tuple, set, etc) paired with any long running or infinite iterator (itertools.count, xrange(sys.maxint), etc). Even the tp_print slot can get caught up in emitting oversized output in a way that is uninterruptable.

I don't see a clean way of teaching all of these functions to periodically check for signals, and either handle them, raise an exception or continue. Fixing this could muck-up and complicate a bunch of otherwise clean code.

Still, it would be nice if everything were interruptable. I'm just not sure it's worth it.

Logged In: YES user_id=593130

Killing the interpreter will, of course, interrupt anything ;-).

The ability to ask the interpreter, via an alternate non-code communication channel, to stop doing what one just requested via the normal code input channel, is an implementation-specific metafeature independent of the language definition. So I see this as a CPython feature- expansion request rather than a bug report.

If the CPython interpreter documentation promises that ^C or whatever will always grab the interpreter's attention, then that overpromise is a bug that should be modified.