[Stackless] Re: [Python-Dev] Stackless pages

Just van Rossum just at letterror.com
Mon Nov 6 21:56:26 CET 2000

[ ... ]
At 9:20 PM +0200 06-11-2000, Christian Tismer wrote:
>Yes, we discussed that in depth, but this is a minor implementation

Sure, but my point is that it makes the _C_ code cleaner, makes it easier
to understand, which will make it easier to get it integrated with the
core. So it is an important issue I'd say. I mean, that's one of the
reasons for the existence of this list, right?

[ ... ]
>But I admit that the stuff might be more understandable by
>explicitly handling the extra system state. I can do this,
>after I know that the patches will make it into the distro, then.
>Without knowing that, not changing but reading was cheaper for me :-)

The current patches won't make it into the distro, because they're too
weird, too hackish. By looking at your code, people will only get scared.
I'm only trying to help making it easier for stackless to become mainstream.

[ call/cc vs. Chris' co API]
>Please show us how you use apply_cc instead of the (admittedly imperfect)
>current "API" without creating more cycles.
>In another thread, please.

That's indeed a weakness. Maybe the cycle GC will help here, too... (But
please don't tell me its _easy_ to avoid cycles with your API...)

Continuations seem inherently problematic with cycles. Conclusion (only
half kidding): if cycles are a problem, continuations are a problem. In my
view, continuation are very useful as abstract concepts, but quite a bit
less useful as actual objects. I'd be happy with just co-routines and

[ co.update() ]
>Please don't shift the topic into the continuation design issue.
>Mixing the two stories makes both less understandable.

Hey! Jeremy started it! ;-)

>Challenge: co.update() can be replaced by a python surrogate
>construct that uses immutable coninuations only. How? :-)

Hah hah. Challenge: programs that use co.update() can easily be rewritten
using immutable continuations. No problem. co.update() is a big fat
stinkin' wart.


Stackless mailing list
Stackless at starship.python.net

More information about the Stackless mailing list