[Python-ideas] Add stop=exception option to next() (was Re: PEP 479 and take())

[Raymond Hettinger]

> On Dec 13, 2014, at 4:39 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> 
> But the current equivalent code in the doc is buggy because it was not.
> 
> def reduce(function, iterable, initializer=None):
>    it = iter(iterable)
>    if initializer is None:
>        value = next(it)

...

> That a core developer would miss this illustrates to me why the addition is needed.  With this proposal, the correct equivalent would be

A number of people seem to take the "python equivalent" code far too literally.  Its purpose is primarily documentation to show the overall logic of reducing.   In some cases you can make the "equivalent" more exact, but make the documentation worse because it starts to lose its explanatory value.

I'm feeling upset by the never ending flurry of proposals on python-ideas.  At their root is doing battle the with the core concept that StopIteration is an exception that can propagate upward like all other exceptions.  There seems to be a not-so-secret wish that StopIteration was a sentinel value that can only be checked immediately and can't be propagated.  In order words, the proponents seem to reject a core idea in the iterator protocol as implemented in Python for over a decade and as implemented in a number of other languages (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Iterators_and_Generators) or as specified in Design Patterns.

In rejecting the notion of StopIteration for control flow, a number of people on this list are going nuts and coming with one random suggestion after another, ignoring the years of success or the experiences of devs in other languages.  You guys seem to be just making up new rules about how other people should write programs to express their reasoning.  Some of the discussed proposals seem like no more than stylistic pedantry.

I wish more people on this list had experience teaching Python.  It would give greater appreciation for language simplicity and not introducing twists in the road.  At one time, all we had was it.next() which either returned a value or raised StopIteration.  Then, next() was added as shortcut for it.__next__().  The relationship was no more special than the relation between len(s) and s.__len__().  Then, next() grew a default argument.  This wasn't bad because it paralleled default arguments in dict.get() and dict.pop() -- also it simplified a common pattern for supplying a default.  But now, you want to add "stop=TypeError("reduce() of empty sequence with no initial value") which has no precedent and must be accompanied by explanation your admonitions about how you want people to always catch StopIteration immediately.   It stops being easily teachable and becomes one more piece of arcana different from the rest of Python, different from the last 15 years of Python iterator thinking, and different from every other iterator protocol implementation in other languages.  I do not look forward to teaching this.

For Christmas, it would be a nice gift if Guido could put an end to this line of thinking.   The conversations are difficult because several of the participants are deeply convinced that there is something fundamentally wrong with StopIteration.  I don't think any of them can easily be convinced to the leave the iterator protocol alone and to continue enjoying one of our best success stories.

sometimes-the-cure-is-worse-than-the-disease-ly,


Raymond


P.S. "Leaking StopIteration" is a phrase that I've only heard here -- this seems to be a villain of legend rather than something that arises in the lives of ordinary Python programmers.