[Python-Dev] PEP 334 - Simple Coroutines via SuspendIteration (original) (raw)

Samuele Pedroni pedronis at bluewin.ch
Wed Sep 8 22:14:54 CEST 2004

Clark C. Evans wrote:

On Wed, Sep 08, 2004 at 09:33:10PM +0200, Samuele Pedroni wrote: | Clark C. Evans wrote: | >I was assuming that only calls within the generator to next(), implicit | >or otherwise, would be suspension points. | | I missed that.

nod I will fix the PEP. | >This covers all of my use cases anyway. In the other situations, if | >they are even useful, don't do that. Convert the SuspendIteration to a | >RuntimeError, or resume at the previous suspension point? | > | >The idea of the PEP was that a nested-generator context provides this | >limited set of suspension points to make an implementation possible. | | then the PEP needs clarification because I had the impression that | | def g(src): | data = src.read() | yield data | data = src.read() | yield data The data producers would all be iterators, ones that that could possibly raise SuspendIteration() from within their next() method. | the read itself could throw a SuspendIteration If read() did raise a SuspendIteration() exception, then it would make sense to terminate the generator, perhaps with a RuntimeError. I just hadn't considered this case. If someone has a clever solution that makes this case work, great, but its not something that I was contemplating.

thinking about it, but this is not different:

def g(src): data = src.next() yield data data = src.next() yield data

def g(src): demand = src.next data = demand() yield data data = demand() yield data

what is supposed to happen here, notice that you may know that src.next is an iterator 'next' at runtime but not at compile time.

More information about the Python-Dev mailing list