[pypy-dev] Stackless PyPy mini sprint 2007

Erik Gorset erik at medallia.com
Mon Sep 17 03:00:51 CEST 2007

On Sep 16, 2007, at 8:13 PM, Christian Tismer wrote:
> Erik Gorset wrote:
>> I'm wondering if there is any plans for pypy/stackless to support
>> true continuations as first class citizen in the future? It would  
>> be easy
>> to implement coroutines and exceptions in normal python code if
>> call/cc was supported. After all, ruby, scheme and smalltalk can
>> support this :-)
> Maybe this is possible, but that's not a reason to do it.
> I have spent a little too much of my lifetime with taming
> continuations. And since Python has all the control flow
> it needs, it does not make sense to add continuations, which
> impose extra complications for no gain.
> I think to stick with coroutines as the building block,
> unless there is a real need for continuations.

Actually, having continuations as a fundamental building block is a
big simplification as all other control flows can be expressed by it.
The only "flaw" is that you can't use the c stack in a normal way
since the executing contexts will form a tree instead of a linear

Of course, we can argue that this isn't pythonic anymore, so I
believe I see your point. I'm already using greenlet extension
for cpython heavily in my code, which is just GREAT :-) So
I can live happily in python without continuations as long as
I have coroutines.

Btw, it's possible to simulate some of call/cc's behavior using
_stackless.fork() (I have a play-implementation lying around here
somewhere). But it has several issues. The biggest one is that fork()
actually copies some of the objects found on the stack. It's been
a while since I've played around with cloneable and fork, so maybe
this has been fixed.

Erik Gorset

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1962 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20070917/477d2f02/attachment.bin>

More information about the Pypy-dev mailing list