[ python-Bugs-1043446 ] Uninterruptable loop

[SourceForge.net]

Bugs item #1043446, was opened at 2004-10-09 06:26
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1043446&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 3
Submitted By: Jp Calderone (kuran)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Uninterruptable loop

Initial Comment:
import itertools
list(itertools.repeat('x'))

^C will not interrupt this.


----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 23:15

Message:
Logged In: YES 
user_id=1188172

What to do here?

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-10-16 00:25

Message:
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.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-10-10 10:06

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1043446&group_id=5470