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

[Devin Jeanpierre]

On Sat, Dec 13, 2014 at 11:51 AM, Chris Angelico <rosuav at gmail.com> wrote:
> Personally, I'd rank them in this order of preference. Consistency
> with generators is a plus (especially in terms of citing a pure-Python
> equivalent), and the second and especially third options risk opening
> up a misfeature - using StopIteration as a weird form of flow
> control/signalling. But your description implies that option 2 is
> inherently obvious, which I'm not entirely convinced of; unless this
> is actually implemented as a generic "this iterator is now exhausted"
> flag, and next() itself sets and checks this flag, thus automatically
> enforcing that one StopIteration will result in an infinite stream of
> StopIterations.

I worded myself poorly. It's not fine, it probably signals a bug in
the callback (which is what makes #1 a reasonable option). What I mean
is that callbacks can return any return value and raise any exception.
Doing so shouldn't cause you to break the documented API of your type,
including breaking its conformance to the iterator protocol. Anyway, I
think we're on the same page, since I agree that your suggestions are
justifiable, and you seem to agree that the status quo is not.

This is not a "consenting adults"-type issue. map() and filter() don't
correctly handle a perfectly plausible case, and as a result they
violate their documented API. That is a bug. I'd rather fix the code
than fix the docs. I can write a patch implementing Chris's #1, if it
would be accepted. I don't think it needs a PEP.

-- Devin