Raymond Hettinger <raymond.hettin...@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 <rep...@bugs.python.org>
<https://bugs.python.org/issue31815>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to