Python 1.6 The balanced language

Tim Peters tim_one at
Thu Sep 7 11:21:17 CEST 2000

[Alex Martelli]
> I'm not sure a generator can be made in Python by just 'wrapping' an
> "enumerative routine" -- you'd need to rework the latter to add
> explicit state/resumption, I think.  But it seems to me that Aahz
> was not talking of Python, the language, as it stands today -- he
> is, after all, taking of 'agreeing on implementation and interface'
> to have this _addition_ to the language.  E.g., a new hypothetical
> Python might have a new keyword, similar to return, that returns
> a pair -- the result being returned, and an 'internal state' needed
> for resumption at the Python instruction just after the newreturn;
> the latter could be a callable-object (to be called without args).
> That might let generators be implemented without, however, allowing
> the full generality of coroutines.  I dunno, I have not looked at
> the current Python sources, but I imagine this is the sort of thing
> they may be mooting...?

Right.  I imagine a PEP will be written eventually with all the gory
details.  In brief, Python already allocates its own "stack frames" off the
heap as just another kind of Python object, so the primary trick in
implementing Icon-style generators with the current VM is simply to refrain
from decrementing the frame's refcount at a return!  The frame object
already contains (almost) all the state it needs to resume from where it
left off.

This is indeed not general enough to support coroutines; the essential
simplifying feature of an Icon-style generator is that it *always*
"suspends" to whoever invoked it (and so, unlike a coroutine, does not
*name* to whom it suspends); in this way it remains strictly stack-like; for
people who like buzzwords <wink>, Knuth calls Icon-style generators
"semi-coroutines"; I've sometimes, and with a bit of success, tried to call
them "resumable functions" on comp.lang.python, to take away some of the
mystery.  In a sense, they do for function-local control flow what C
"static" does for function-local data:  preserves it "across

The implementation is easy to explain, so it may be a good idea <wink>.

More information about the Python-list mailing list