Just a few clarifications. I have no time, but need to share what I learned. Tim Peters wrote:
[Guido and Tim, Guido and Tim]
...
Among the three {coroutines, fake threads, continuations}, I expect any could be serviceably simulated via either of the others. There: just saved a full page of sentence diagramming <wink>. All offer a strict superset of generator semantics.
I have just proven that this is not true. Full continuations cannot be expressed by coroutines. All the rest is true. Coroutines and fake threads just need the absence of the C stack. To be more exact: It needs that the current state of the C stack is independent from executing bound Python code (which frames are). Now the big surprize: This *can* be done without removing the C stack. It can give more speed to let the stack wind up to some degree and wind down later. Even some Scheme implementations are doing this. But the complexity to make this work correctly is even higher than to be stackless whenever possible. So this is the basement, but improvements are possible and likely to appear. Anyway, with this, you can build fake threads, coroutines and generators. They all do need a little extra treatment. Switching of context, how to stop a coroutine, how to catch exceptions and so on. You can do all that with some C code. I just believe that even that can be done with Python. Here the unsayable continuation word appears. You must have them if you want to try the above *in* Python. Reason why continuations are the hardest of the above to implement and cannot expressed by them: A continuation is the future of some computation. It allows to change the order of execution of a frame in a radical way. A frame can have as many as one dormant continuation per every function call which appears lexically, and it cannot predict which of these is actually a continuation.