Home Original page

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

random832 at fastmail.us random832 at fastmail.us
Mon Dec 15 18:37:26 CET 2014 
On Sat, Dec 13, 2014, at 14:51, Chris Angelico wrote:
> I'm not sure that "fine and to be expected" is necessarily true. If
> the function given to map() raises StopIteration, I'd say any of these
> approaches is justifiable:
> 1) It's an error. Raise something other than StopIteration, so the
> caller knows something bad happened. (A generator version of map()
> will do this post-479.)
> 2) It's to be expected. Consider map() to have now terminated. (In
> other words, catch it and return.)
> 3) It's a signal that this one element should not be returned.
> Suppress it, yield nothing, and go get the next value from the input
> iterator.
> 
> 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),

It's worth mentioning that #2 is, more or less,* precisely how both map
and a pure-python equivalent behaved before PEP 479. Some people in this
discussion considered this expected. Obviously that was not the end of
the discussion.

*Assuming that the code consuming the outer iterator will not attempt to
read it again after a single StopIteration has been raised. A
well-behaved iterator will continue to raise StopIteration forever after
it has raised it once - an iterator whose StopIteration has been caused
by some inner function will not.
More information about the Python-ideas mailing list