This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author scoder
Recipients gvanrossum, lukasz.langa, martin.panter, pitrou, rhettinger, scoder, vstinner, yselivanov
Date 2015-04-21.04:57:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Here's a new patch that addresses the review comments. I kept throw() and close() non-abstract and added an example to the tests instead that implements a minimal generator by inheriting these methods from the Generator base class, using it as a mixin. It only needs to implement send().

I don't think it's unreasonable to assume that there are use cases where a generator that is implemented in a class instead of a yield-function does not require special cleanup actions in its close()/throw(). Or is it *required* that a generator stops working when close() is called?

There are also iterators that raise StopIteration at some point to signal that they are temporarily exhausted, but then eventually restart returning values from their __next__() method when they have received more to return. Avoids recreating the iterator object after each exhaustion cycle.

I extended the default implementation of close() to call throw(GeneratorExit), though, because that's how the protocol is defined. Unless users implement throw(), it won't make a difference for them. And if they do, they may even get away with not reimplementing close().
Date User Action Args
2015-04-21 04:57:55scodersetrecipients: + scoder, gvanrossum, rhettinger, pitrou, vstinner, lukasz.langa, martin.panter, yselivanov
2015-04-21 04:57:55scodersetmessageid: <>
2015-04-21 04:57:55scoderlinkissue24018 messages
2015-04-21 04:57:55scodercreate