[Python-ideas] Revised**10 PEP on Yield-From

[Jacob Holm]

Nick Coghlan wrote:
> Jacob Holm wrote:
>>    * The "what should close() do if it catches StopIteration with a
>>      value" issue I don't think we have resolved either way.  Since we
>>      are not going to store the value, only the first close() would be
>>      able to return it.  Under those conditions, I no longer think that
>>      returning the value is a good idea.  If we are not storing or
>>      returning the value, I think close() should raise an exception.
>>      Either reraise the StopIteration, so that the caller has a chance
>>      to get the value that way, or raise a RuntimeError, because it is
>>      meaningless to return a value as response to a GeneratorExit when
>>      that value cannot later be accessed by anything and it is
>>      therefore most likely a bug.
> 
> If you care about a generator's return value *don't* just call "close()"
> on it. Use "throw(GeneratorExit)" instead so you can catch the exception
> and interrogate the return value yourself.
> 

I already know I can do that.  My point was that if close is defined to 
not return the value, then returning a value in response to a 
GeneratorExit is suspect and likely to be a bug in the generator.

I have since realised that there can be valid cases where being able to 
share the exit code path between the normal and GeneratorExit cases 
simplifies things.  Also, Greg has convinced me that the type of error I 
was worried about is not specific to generators, so there is no 
particular reason to do the extra work of detecting them here.

So I now agree we can swallow the return value without raising an exception.

Cheers
- Jacob