[Python-ideas] x=(yield from) confusion [was:Yet another alternative name for yield-from]

[Jacob Holm]

Nick Coghlan wrote:
> Jacob Holm wrote:
>   
>> Another option (if you insist that it is an error to return a value
>> after a GeneratorExit) is to let close() raise a RuntimeError when it
>> catches a StopIteration with a non-None value.
>>     
>
> Why do you consider it OK for close() to throw away all of the values
> the generator might have yielded in the future, but not OK for it to
> throw away the generator's return value? 

Because the return value is actually computed and returned from the 
generator, *then* thrown away.  If there is no way to access the value, 
it should be considered an error to return it and flagged as such.  What 
the generator might have yielded if close wasn't called doesn't interest 
me the slightest.

> The objection I have to having
> close() return a value is that it encourages people to start using
> GeneratorExit in their normal generator control flow and I think that's
> a really bad idea (on par with calling sys.exit() and then trapping
> SystemExit to terminate a search loop - perfectly legal from a language
> point of view, but a really bad plan nonetheless).
>   

Yes, I understand that this is how you think of GeneratorExit.

> Now, the fact that repeatedly calling next()/send()/throw() on a
> finished generator is meant to keep reraising the same StopIteration
> that was thrown when the generator first terminated is a *much* better
> justification for preserving the return value on the generator object.
>   

Ok

> But coupling that with the idea of close() doing anything more than
> giving an unfinished generator a final chance to release any resources
> it is holding is mixing two completely different ideas.
>
> Better to just add a "value" property to generators that raises a
> RuntimeError if the generator frame hasn't terminated yet (probably
> along with a "finished" property to allow LBYL interrogation of the
> generator state).
>   

Why not a single property raising AttributeError until the frame is 
terminated?  (Not that I really care as long as I can access the value 
without having access to the original StopIteration).

If the value is stored, I am fine with close not returning it or raising 
an exception.

- Jacob