[Python-ideas] Map and filter should also convert StopIteration to RuntimeError
tjreedy at udel.edu
Sun Dec 14 00:37:16 CET 2014
On 12/13/2014 3:48 PM, Guido van Rossum wrote:
> On Fri, Dec 12, 2014 at 10:10 PM, Raymond Hettinger
> <raymond.hettinger at gmail.com
> <mailto:raymond.hettinger at gmail.com>> wrote:
> > On Dec 12, 2014, at 4:36 PM, Greg Ewing <greg.ewing at canterbury.ac.nz
> <mailto:greg.ewing at canterbury.ac.nz>> wrote:
> > Terry Reedy wrote:
> >> PEP 479 reverses this acceptance by having generator.__next turn StopIteration raised in a user-written generator function body into a RuntimeError. I propose that other builtin iterator.__next__ methods that execute a passed in function do the same.
> > Maybe also any user-written function whose
> > name isn't "__next__"?
> That does seem to be where this is headed :-(
> I'm -1 on this proposal.
> Me too. PEP 479 was a clear win. __next__ methods are a much murkier
> area and we should not mess with them.
After reading other responses, even before reading this one, I decided
that Alexander Belopolsky's initial comment "Aren't we stepping on a
slippery slope here?" was correct, that generator.__next__ and generator
functions are a sufficiently unique case to get unique treatment, and
that I would withdraw my proposal. [The rest of Guido's post, which I
have snipped, further explicates the slipperness.] I am also cognizant
that creating incompatibilities between even 3.4 and 3.5 requires strong
justification. So I consider this trial balloon popped.
My proposal was a response to the problem of *silent breakage* of
'transform iterators' that take as arguments an iterator and transform
function and produce a new, transformed sequence. While breaking
functions with bad input generally falls under 'consenting adults', a
transform function raising StopIteration is special in that it can
easily lead to silent rather than noisy breakage.
I have two alternate proposals.
1. In the doc entry for StopIteration, explicitly recommend against
raising StopIteration outside of __next__ methods on the basis that
doing so can lead to silent breakage of iterators. Then writing
functions that do so anyway or passing them into iterators will clearly
be a 'consenting adults' issue.
2. Make it easier to avoid accidentally leaking StopIteration when using
next() by adding an option to have it raise a different exception. I
already posted this idea to a different thread.
Terry Jan Reedy
More information about the Python-ideas