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/