FWIW, this doesn't seem to be solving any real life problems, only contrived examples.  If any changes are made, they should be very restricted in scope, taking care to not wreck the performance of tools designed for speed and not to add useless crud to otherwise clean code.

I think thought needs to be given to the question of whether there is a general purpose means of interrupting C code.  The real world problems I see occurring aren't trivial examples like sum(itertools.count()) -- what people routinely bump into is IDLE's use of Tkinter becoming unresponsive, numpy being asked to apply a high algorithmic complexity transformation to too large of matrix, mistakes during development with ctypes, etc.  In other words, we should collect a list of real problems that cause a spinning wheel of death, rather than cases where the user specifically asked for an infinite summation.

If there are patches aimed at the toy examples, I think the emphasis should be on the consumer side (min, max, sum, list, sorted, etc) rather than on the producer side (i.e. itertools).  One reason to focus on the consumer side is that we control more of those (the world is full of third-party C extension producers).  Another reason is the lazy-evaluation style of functional programming puts the termination responsibility with consumers to provide the most flexibility in grouping the tools (see http://worrydream.com/refs/Hughes-WhyFunctionalProgrammingMatters.pdf ).  Lastly, the focus on the consumer is suggested by itertools programming patterns (i.e. chains of nested iterators driven by a single consumer of mapping/zipping together infinite iterators with a single finite iterator such as map(somefunc, count(), repeat(somearg), repeat(otherarg))).  In those cases, focusing on the many producers would result in many repeated checks per iterator; whereas, focusing on the consumer would give only one check per iteration.

In thinking about the real world issues I've seen, ISTM we should worry instead about unbounded consumption of memory resources without demanding that a user realize what is going on and making them jump in with a Cntl-C before something bad happens.  If you run list(range(100000000000)), memory will fill, then thrash your SSD with swaps, and make your CPU melt.