On Sun, Nov 16, 2014 at 1:13 AM, Nick Coghlan <firstname.lastname@example.org> wrote:
>> For certain situations, a simpler and fully backward-compatible
>> solution may be sufficient: when a generator returns, instead of
>> raising ``StopIteration``, it raises a specific subclass of
>> ``StopIteration`` which can then be detected. If it is not that
>> subclass, it is an escaping exception rather than a return statement.
> There's an additional subtlety with this idea: if we add a new
> GeneratorReturn exception as a subclass of StopIteration, then generator
> iterators would likely also have to change to replace GeneratorReturn with a
> regular StopIteration (chaining appropriately via __cause__, and copying the
> return value across).
Would have to do so automatically, meaning this is no simpler than the
current proposal? Or would have to be always explicitly written to
> I definitely see value in adding a GeneratorReturn subclass to be able to
> tell the "returned" vs "raised StopIteration" cases apart from outside the
> generator (the current dance in contextlib only works because we have
> existing knowledge of the exact exception that was thrown in). I'm
> substantially less convinced of the benefit of changing generators to no
> longer suppress StopIteration. Yes, it's currently a rather odd corner case,
> but changing it *will* break code (at the very least, anyone using an old
> version of contextlib2, or who are otherwise relying on their own copy of
> contextlib rather than standard library one).
This is why it's proposed to use __future__ to protect it.
still using an old version of contextlib2 once 3.7 comes along, it'll
break; but is there any reason to use Python 3.7 with a contextlib
from elsewhere than its standard library?
(I'm not familiar with
contextlib2 or what it offers.)