On 12/13/2014 3:48 PM, Guido van Rossum wrote:
On Fri, Dec 12, 2014 at 10:10 PM, Raymond Hettinger
mailto:raymond.hettinger@gmail.com> wrote: > On Dec 12, 2014, at 4:36 PM, Greg Ewing mailto:greg.ewing@canterbury.ac.nz> wrote: > > Terry Reedy wrote: >> 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. > > Maybe also any user-written function whose > name isn't "__next__"? That does seem to be where this is headed :-(
I'm -1 on this proposal.
Me too. PEP 479 was a clear win. __next__ methods are a much murkier area and we should not mess with them.
After reading other responses, even before reading this one, I decided that Alexander Belopolsky's initial comment "Aren't we stepping on a slippery slope here?" was correct, that generator.__next__ and generator functions are a sufficiently unique case to get unique treatment, and that I would withdraw my proposal. [The rest of Guido's post, which I have snipped, further explicates the slipperness.] I am also cognizant that creating incompatibilities between even 3.4 and 3.5 requires strong justification. So I consider this trial balloon popped. My proposal was a response to the problem of *silent breakage* of 'transform iterators' that take as arguments an iterator and transform function and produce a new, transformed sequence. While breaking functions with bad input generally falls under 'consenting adults', a transform function raising StopIteration is special in that it can easily lead to silent rather than noisy breakage. I have two alternate proposals. 1. In the doc entry for StopIteration, explicitly recommend against raising StopIteration outside of __next__ methods on the basis that doing so can lead to silent breakage of iterators. Then writing functions that do so anyway or passing them into iterators will clearly be a 'consenting adults' issue. 2. Make it easier to avoid accidentally leaking StopIteration when using next() by adding an option to have it raise a different exception. I already posted this idea to a different thread. -- Terry Jan Reedy