[Python-Dev] PEP 479: Change StopIteration handling inside generators

[Steven D'Aprano]

On Sun, Nov 23, 2014 at 08:17:00AM -0800, Ethan Furman wrote:

> While I am in favor of PEP 479, and I have to agree with Raymond that 
> this isn't pretty.
> 
> Currently, next() accepts an argument of what to return if the 
> iterator is empty.  Can we enhance that in some way so that the 
> overall previous behavior could be retained?
[...]
> Then, if the iterator is empty, instead of raising StopIteration, or 
> returning some value that would then have to be checked, it could 
> raise some other exception that is understood to be normal generator 
> termination.

We *already* have an exception that is understood to be normal 
generator termination. It is called StopIteration.

Removing the long-standing ability to halt generators with 
StopIteration, but then recreating that ability under a different name 
is the worst of both worlds:

- working code is still broken;
- people will complain that the new exception X is silently swallowed by 
  generators, just as they complained about StopIteration;
- it is yet another subtle difference between Python 2 and 3;
- it involves a code smell ("no constant arguments to functions");
- and does nothing to help generators that don't call next().

The current behaviour is nice and clean and has worked well for over a 
decade. The new behaviour exchanges consistency in one area (generators 
behave like all other iterators) for consistency in another (generator 
expressions will behave like comprehensions in the face of 
StopIteration). But trying to have both at the same time via a new 
exception adds even more complexity and would leave everyone unhappy.



-- 
Steven