[Python-Dev] PEP 334 - Simple Coroutines via SuspendIteration

[Samuele Pedroni]

Clark C. Evans wrote:

> On Wed, Sep 08, 2004 at 08:58:21PM +0200, Samuele Pedroni wrote:
> | If I understand the proposal (which is quite vague), like restartable 
> | syscalls, there is also the matter that whatever raised the 
> | SuspendIteration should be retried on resumption of the generator, e.g 
> | calling nested generator next.
> 
> That's exactly the idea.  The SuspendIteration exception could contain,
> however, the file/socket that it is blocked on, so a smart scheduler
> need not be blindly restarting things.
> 
> | So one would have to cherry pick for each bytecode or similar abstract
> | operations model relevant suspension/resumption points and it would 
> | still be quite a daunting task to implement this adding the code
> | for intra bytecode resumption. (Of course this assumes that capturing
> | the C stack and similar techniques are out of question)
> 
> I was assuming that only calls within the generator to next(), implicit
> or otherwise, would be suspension points.

I missed that.

> 
> 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 read itself could throw a SuspendIteration, and upon the sucessive 
next the src.read() itself would be retried. But if it's only nexts than 
can be suspension points then the generator would be not resumable in 
this case. Which is the case?