[Python-Dev] Please reconsider PEP 479.

[Olemis Lang]

On 11/23/14, Mark Shannon <mark at hotpy.org> wrote:
>
[...]
>
> You are grouping next() and it.__next__() together, but they are different.
> I think we agree that the __next__() method is part of the iterator
> protocol and should raise StopIteration.
> There is no fundamental reason why next(), the builtin function, should
> raise StopIteration, just because  __next__(), the method, does.
> Many xxx() functions that wrap __xxx__() methods add additional
> functionality.
>
> Consider max() or min(). Both of these methods take an iterable and if
> that iterable is empty they raise a ValueError.
> If next() did likewise then the original example that motivates this PEP
> would not be a problem.
>

FWIW , I fully agree with this . My (personal) impression about PEP 479 is that

1. All the drawbacks mentioned by Raymond Hettinger ,
    Nick Coghlan et al. in the other thread are **really** serious
2. The PEP actually over-complicates the so-far-*natural* definition of
    the iterator protocol for generators ... and proposed solution adds more
    issues than it really solves .
3. "The fault is with next() raising StopIteration. Generators raising
    StopIteration is not the problem." since the later is just an instance
    of sub-typing whereas the former is more about an exceptional branch

>>
>> I'm not sure what you mean by your "However" above. In both __next__
>> and next(), this is a signal; it becomes an error as soon as you call
>> next() and don't cope adequately with the signal, just as KeyError is
>> an error.
>>
>>> 2. The proposed solution does not address this issue at all, but rather
>>> legislates against generators raising StopIteration.
>>
>> Because that's the place where a StopIteration will cause a silent
>> behavioral change, instead of cheerily bubbling up to top-level and
>> printing a traceback.
> I must disagree. It is the FOR_ITER bytecode (implementing a loop or
> comprehension) that "silently" converts a StopIteration exception into a
> branch.
>
> I think the generator's __next__() method handling of exceptions is
> correct; it propogates them, like most other code.
>

This is really true and is the basis for composing generator
expressions (the discussion's been too long I do not want to add more
examples to emphasize this point) . IMHO StopIteration should be
propagated up to the caller in the context of iterator composition
(i.e. definition) as opposite to the case of client code actually
*using* (i.e. consuming) the generator (and the difference between
both scenarios is somehow similar to has-a vs is-a in classical OO
subtyping scenarios) . In the later case (use) raising ValueError or
RuntimeError (I'd prefer the former) would be really helpful , so I
really favor doing so in next() method rather than over-complicating
generators (and breaking the iterator subtype condition) for no good
(IMHO) reason .

[...]

p.s. I know that the PEP has been accepted by the BDFL , but I really
think this is an important concern , that's why I insist for the sake
of helping ... in case this represents a serious violation of
established rules please send me a private message and I will not do
it again (... but I'm hoping , after all, that post-acceptance debate
will not be considered as harmful when there's a good reason according
to someone ...)

-- 
Regards,

Olemis - @olemislc

Apache(tm) Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article: