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