stackless python

[Tim Peters]

[Paul Rubin]
> The limitations of "simple generators" also seem kind of artificial--
> maybe Stackless for 2.2 can support calling a generator from multiple
> places.

[Christian Tismer]
> Sure, Stackless generators are not limited. They are first class
> objects which can be used everywhere.

So are 2.2's Simple Generators.  Paul is confused if he thinks a Python
generator can't be called from multiple places (although that's not typical
use).  Since they're just objects that implement the 2.2 iterator protocol,
we *can't* stop them from getting called from multiple places <wink>.

> Just think of ICON's co-expressions.

Python's generators are between Icon's generators and Icon's co-expressions:
like an Icon coexp, they can be resumed at will independent of control
context (although it's more usual to let "for" loops drive them by magic),
but like an Icon generator they always return control to their resumer.  A
subtle advantage of the latter is that semantics in case of unhandled
exception are very clear:  an active instance of a Python generator "came
from" an obvious place, and that's the obvious place to pass on an unhandled
exception.

BTW, Neil Schemenauer had no trouble rewriting all "the usual" coroutine
examples to use Simple Generators instead.  It remains debatable whether
coexps are actually more powerful; in general, a Python-level dispatch loop
can keep around any number of Simple Generators suspended in midstream
(including chains of generators, recursive or otherwise), and coexp-like
transfer can then be faked by yielding back to the dispatch loop with an
indication of which generator you want to see resumed next.  Neil didn't
need all that machinery to handle the examples he tried, though.  I expect
that if someone bothered to flesh this all out, the rub would be that
resuming a generator chain N deep (ditto yielding back from one) requires
time proportional to N.

if-you-don't-avoid-the-c-stack-you-have-to-rebuild-it-each-time-ly
    y'rs  - tim