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

[Samuele Pedroni]

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.