[Stackless] Re: [Python-Dev] Stackless pages
tismer at tismer.com
Mon Nov 6 21:27:14 CET 2000
Just van Rossum wrote:
> [ ... ]
> 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?
Yes, of course. I just think we have too much topics
in one thread, and we might loose focus.
> [ ... ]
> >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.
Thanks for the compliments.
> I'm only trying to help making it easier for stackless to become mainstream.
Shure. The first thing was to make it work at all.
The second thing is to make it nice.
> [ 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...)
No it is not easy.
Implementing coroutines and stuff on top of first-class continuations
is possible, but it is hard to avoid cycles.
It is easier to implement them directly, handling continuation-alike
objects (or less) inside of suitable objects.
Since the latter is the goal, I don't see a priority for
discussing the continuation API at the moment, since this
is transient, experimental stuff.
And having Neil's GC, the game in fact looks different,
and many reasons for the current API might vanish.
> 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
Ok. I'd say it so: Continuations are problematic with cycles
when they are exposed as first-class objects, since then you
have variables which hold references and so on.
They don't harm when they are kept under the cover of
> [ co.update() ]
Danger! Please do not use co.update. (ouch!)
Typing "co.update" grows big fat warts at your fingertips!
My apologies for creating such a bad function.
I will remove the doc string and await the Spanish Inquisition :-)
ciao - chris
Christian Tismer :^) <mailto:tismer at tismer.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Kaunstr. 26 : *Starship* http://starship.python.net
14163 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
where do you want to jump today? http://www.stackless.com
Stackless mailing list
Stackless at starship.python.net
More information about the Stackless