On Nov 15, 2014, at 1:29 AM, Chris Angelico <rosuav@gmail.com> wrote:

Abstract
========

This PEP proposes a semantic change to ``StopIteration`` when raised
inside a generator, unifying the behaviour of list comprehensions and
generator expressions somewhat.


Please let me know if I'm reading the PEP correctly.
Does the proposal break all existing code in generators
that uses next() to raise StopIteration or that raises
StopIteration explicitly?

For example, here is the pure python recipe for itertools.accumulate()
show in the docs at https://docs.python.org/3/library/itertools.html#itertool-functions :


    def accumulate(iterable, func=operator.add):
        'Return running totals'
        # accumulate([1,2,3,4,5]) --> 1 3 6 10 15
        # accumulate([1,2,3,4,5], operator.mul) --> 1 2 6 24 120
        it = iter(iterable)
        total = next(it)
        yield total
        for element in it:
            total = func(total, element)
            yield total

Or would it break the traditional examples of how to write something
like izip() using a generator?

    def izip(iterable1, iterable2):
        it1 = iter(iterable1)
        it2 = iter(iterable2)
        while True:
            v1 = next(it1)
            v2 = next(it2)
            yield v1, v2

    assert list(izip('ab', 'cde')) == [('a', 'c'), ('b', 'd')]
    assert list(izip('abc', 'cd')) == [('a', 'c'), ('b', 'd')]

My initial reading of the PEP was a bit unsettling because the listed
examples (such as unwrap() and parser()) were a series of cases 
where code that was currently working just fine for the last decade
would break and need be changed to less pleasant looking code.

Also, the PEP motivation seemed somewhat weak.  Instead of listing
known bugs or real-world development difficulties, it seems to hinge
almost entirely  some "being surprised" that list comprehensions and
generator expressions aren't the same in every regard (they aren't).

AFAICT, that suggestion is that an incorrect expectation of perfect symmetry
warrants a number of what the author calls "consequences for existing code".

It seems that if the real problem is one of false expectations or surprises,
the direct solution would be to provide clearer examples of how things
actually work and to disabuse the idea that list comprehensions and
generator expressions are more interchangeable than they actually are.


Raymond


P.S.   On a more general note, I think that our biggest problem
in the Python world is getting people to switch to Python 3.
If we really want that to happen, we should develop a strong
aversion to proposals that further increase the semantic
difference between Python 2 and Python 3.