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

[Nick Coghlan]

On 13 December 2014 at 07:14, Terry Reedy <tjreedy at udel.edu> wrote:
> " exception StopIteration
>     Raised by built-in function next() and an iterator‘s __next__() method
> to signal that there are no further items produced by the iterator."
>
> I have always taken this to mean that these are the only functions that
> should raise StopIteration, but other have not, and indeed, StopIteration in
> generator functions, which are not __next__ methods, has been accepted and
> passed on by generator.__next__.  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.

No, Oscar's proposal is based on a fundamental misunderstanding of the
problem PEP 479 is solving. The PEP solves a generator specific
problem with having "Two Ways to Do It" when it comes to terminating
generator functions. It does this by way of the relatively
straightforward expedient of having the PEP 380 approach completely
replace the legacy approach, rather than retaining the status quo of
offering both in parallel (my attempt at explaining this perspective
in more detail:
https://mail.python.org/pipermail/python-ideas/2014-December/030371.html).

__next__ methods in general don't have this problem - there's only one
way to signal termination from a __next__ method implementation, and
that's raising StopIteration.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia