[Python-ideas] Map and filter should also convert StopIteration to RuntimeError

[Terry Reedy]

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