import itertools
list(itertools.repeat('x'))

^C will not interrupt this.

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.

Logged In: YES 
user_id=1188172

What to do here?

Logged In: YES 
user_id=849994

Turning into a feature request.