[Python-Dev] Minimal 'stackless' PEP using generators?

Phillip J. Eby pje at telecommunity.com
Mon Aug 23 21:34:13 CEST 2004


At 03:18 PM 8/23/04 -0400, Clark C. Evans wrote:
>On Mon, Aug 23, 2004 at 02:59:18PM -0400, Phillip J. Eby wrote:
>| >    def generator():
>| >        yield 'one value'
>|     value, = generator()
>Oh, cool.  ;)
>
>| > Full-blown corountines arn't necessary.  A small tweak to
>| > to generators will do.
>|
>| I don't think this is true.  Your hypothetical example can't resume
>| 'top()' after it yields the "co-operate" control value, unless it either
>| it *has* a stack of generators, or the Python core somehow maintains a
>| stack of the executing generators.
>
>Yes.  The idea is for Python to maintain a stack of generators, and when
>ever the top-most generator yields <magic> this yield skips the
>intermediate generators on the stack, and goes immediately to the
>calling function.

That's not the part I mean.  I'm talking about *after* that happens, when 
you *resume* the generators, and you'll need to reconstruct the stack as it 
stood when the generators were interrupted.

(Your original proposal doesn't actually mention this part at all, but I 
assume it's necessary.  After all, if all you needed was a way to stop a 
bunch of generators in their tracks, raising an exception would suffice.)


>| So, my point was that since this can already be done in user-level code
>| with a stack of generators, I don't see the point to adding a facility to
>| Python to create hidden stacks of generators.
>
>The problem is, if you maintain the stack of generators in userland,
>then each generator on the stack must do special stuff to handle
>'cooperate' (in one form or another).  You demonstrated an equivalent
>problem with your peek.event code presented earlier.  While, if this is
>built into the core, intermediate generators can be happily oblivious to
>the cooperative magic.

Though the problems are "equivalent" in complexity, the difficulty of their 
respective solutions are not at all comparable, because your approach 
either requires a technique for dynamically reconstructing the stack, or 
some similar mechanism for generators to keep track of the state of *other* 
generators when the containing generator is interrupted.



More information about the Python-Dev mailing list