On Sun, 8 Dec 2019 at 14:37, Chris Angelico <ros...@gmail.com> wrote:
>
> PEP 479 (https://www.python.org/dev/peps/pep-0479/) changed the rules
> around generators: if it would have leaked StopIteration, it instead
> raises RuntimeError. This converts hard-to-debug premature termination
> into easily-spotted exceptions, but it applies only to actual
> generator functions.
[snip]
> I propose to grant PEP 479 semantics - namely, that a StopIteration
> during the calling of the mapped function be translated into a
> RuntimeError. Likewise for filter(), guarding the predicate function,
> and all similar functions in itertools: accumulate, filterfalse,
> takewhile/dropwhile, starmap, and any that I didn't notice.

The problem here is that in the case of generators there is a single
place that you can fix this in the implementation of generators in the
interpreter as part of the definition of the language. With iterators
there are many iterator tools including in third party code outside of
the stdlib. They won't all be fixed so it would remain the case that
bare next should be discouraged in most uses and that there isn't a
drop-in replacement for someone who just wants to use next without a
default value.

I think you will also find that much code is depending on map etc to
behave in the current way. When learning the iterator protocol it
seemed to me that being able to raise StopIteration from anywhere was
a design feature.

--
Oscar
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SSVX4MXXWVWKPO3V6MB3YV2VHITYP4QZ/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to