[issue31815] Make itertools iterators interruptible

[Raymond Hettinger]

Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I respectfully disagree that this just happens to people accidentally -- Every single day, I work with either Python professionals or Python students and never see this situation occur, nor have I had a single report of it from one of my clients, ever.  In my experience, someone has to be trying to produce exactly this effect.  

They have to go out of their way to import a high-performance module, select one of the tools specifically documented to be infinite, specifically reach for one the very few tools like repeat() or count() that don't make any pure python callbacks, and then separately reach for a high-performance consumer that makes no pure python callbacks.  People don't just write ``sum(itertools.count()`` to do something useful, they do it just to see if they can produce exactly this effect.

We have a number of areas where we're comfortable saying "just don't do that" (i.e. the repr of a large number or of a large container, repeated exponentation, bytecode hacks, ill-formed ctypes, etc).

I would like to draw a line in the sand for itertools to not go down this path unless we actually see this happening in the wild to people not trying to do it on purpose.  It is much more likely that a user with accidentally types ">>> 'x' * 1000000000" and gets the same effect.

On a side note, I have a fear (possibly rational, possibly not) that introducing signal handling into formerly atomic operations will open up new classes of bugs and usability problems (i.e. Issue #14976 showed that when GC gained the ability trigger calls to __del__, it created queue reentrancy deadlock problems that could not be solved with pure python code).

One last thought -- the various core devs seem to be charging in opposite directions.  On the one hand, there seems to be no limit to the coding atrocities being considered to save under a millisecond of startup time and for various other questionable mirco-optimizations.  And on the other hand, there seems to be a great deal of willingness to inject almost-never-needed error checks or signal handling into otherwise tight, high-volume code paths.   One group likes to refactor code to make it clean and easy to maintain and stick with its business purpose, while another group is comfortable garbaging-up code in order to achieve some other benefit that may not be in line with the module designer's intent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31815>
_______________________________________