[Python-Dev] Stackless Python - Pros and Cons (original) (raw)

Tim Peters tim_one@email.msn.com
Sun, 6 Aug 2000 18:07:45 -0400

[ Eric S. Raymond]

... I want this feature [generators] a lot. Guido has agreed in principle that we ought to have generators, but there is not yet a well-defined path forward to them. Stackless may be the most promising route.

Actually, if we had a PEP , it would have recorded for all time that Guido gave a detailed description of how to implement generators with minor changes to the current code. It would also record that Steven Majewski had already done so some 5 or 6 years ago. IMO, the real reason we don't have generators already is that they keep getting hijacked by continuations (indeed, Steven gave up on his patches as soon as he realized he couldn't extend his approach to continuations).

I was going to explain coroutines separately, but I realized while writing this that the semantics of "yield" proposed above actually gives full coroutining.

Well, the Icon semantics for "suspend"-- which are sufficient for Icon's generators --are not sufficient for Icon's coroutines. It's for that very reason that Icon supports generators on all platforms (including JCon, their moral equivalent of JPython), but supports coroutines only on platforms that have the magical blob of platform-dependent machine-language cruft needed to trick out the C stack at coroutine context switches (excepting JCon, where coroutines are implemented as Java threads).

Coroutines are plain harder. Generators are just semi-coroutines (suspend/yield always return "to the caller", and that makes life 100x easier in a conventional eval loop like Python's -- it's still "stack-like", and the only novel thing needed is a way to resume a suspended frame but still in call-like fashion).

and-if-we-had-a-pep-every-word-of-this-reply-would-have-been- in-it-too-ly y'rs - tim