[Python-ideas] Revised**10 PEP on Yield-From
jh at improva.dk
Sat Apr 18 14:20:46 CEST 2009
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.
More information about the Python-ideas