On 11/23/14, Mark Shannon <m...@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: _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com