Bruce Frederiksen wrote:
Jacob Holm wrote:
I think it would be better not to loop, still return the final value from close, and still just throw GeneratorExit to subiterators without trying to reraise. This sounds better to me too, except for the last part -- not reraising GeneratorExit.
If you re-define close to return the value attached to StopIteration, then I think that it makes sense to define it to continue to return this value on subsequent calls to close. This provides a way to still retrieve the returned value after the generator has been finalized in some other way.
If we want close to return the value multiple times we need to store it somewhere. If we are storing it, we might as well do it as a direct result of the return statement instead of pulling it out of the StopIteration. That way we could drop the idea of a GeneratorReturn exception and just always call close on the subiterator to get the value. If we are calling close anyway, we don't need to pass the GeneratorExit to the subiterator ourselves, as close will do it for us. But if we don't pass it to the subiterator, we need to (re)raise it in the yield from. That makes this a slight variation of my #4, which IIRC was a common preference between you and Nick (and probably Greg as well).
And then, wouldn't this allow you to discard the StopIteration in yield from and reraise GeneratorExit to finalize the outer generator; but leaving it the option to call close itself on the inner generator to retrieve the return value, if it still wants it?
Yes it would. This addresses the issue I had about not being able to retrieve the return value after yield-from throws GeneratorExit. At the moment, I can't find any other issues with this version. The only slight drawback is that it has to save the returned value, potentially keeping it alive longer than necessary. This is more than compensated for by making things simpler and allowing more uses, such as using the generator in a for-loop and accessing the return value afterwards. So +1 to this. - Jacob