Jacob Holm wrote:
Well-behaved generators would not be affected, but there might be generators in real use that relied on the ability to ignore close or code using such generators that relied on getting the RuntimeError.
I think that's stretching things a bit. To my mind, any code that *relies* on getting a RuntimeError is just perverse -- sort of like saying that the code is only correct if it has a bug in it.
the "yield raise" expression. The purpose of this would be to raise an exception in the caller of "next", "send", "throw" or "close" *without* finalizing the generator. Extending my "averager" example a bit:
Sorry, but your example is now so convoluted that I can't follow it. I would never recommend that anyone write code like that.
Only true because you have redefined it so that no generators are broken.
Not quite -- a generator that gets into an infinite loop catching GeneratorExits would still be broken, you just wouldn't be told about it with an exception. But it's true that the class of non-broken generators would be considerably expanded. I would argue that the generators being included were unfairly classified as broken before, because they simply hadn't been given enough opportunity to finalize themselves.
The possibility of turning a call that used to raise a RuntimeError into an infinite loop bothers me a bit.
I still have trouble believing that this will be a serious problem in practice. I suspect it will occur quite rarely, and if it does occur, you debug it using the usual techniques for diagnosing an infinite loop. Hit Ctrl-C, examine the traceback, and do some poking around.
To summarize, I am only +0.75 on this proposal. 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.
But we've established that this combination makes it very easy to create broken generators through no fault of your own. That's not acceptable to my mind. -- Greg