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

Christian Tismer tismer at tismer.com
Mon Nov 6 19:24:30 CET 2000

Ok, a few comments, not trying to write a PEP here :-)

Jeremy Hylton wrote:
> >>>>> "SM" == Skip Montanaro <skip at mojam.com> writes:
>   Gordon> If we can't overcome "ew - a call might not ever return"
>   Gordon> there's not much sense in writing the PEPs.
>   SM> I disagree.  The value in writing a stackless PEP is that those
>   SM> who would dismiss the idea out-of-hand or those who think they
>   SM> understand it but really don't might gain some insight into
>   SM> what's really going on.
> +1
> I am probably in the "think I understand it but really don't" camp.
> Since there have been few dissenting opinions so far, I assume I am
> also the person to whom "ew - call might not ever return" should be
> attributed.  (I didn't think I said that, though.)
> I should clarify exactly what I am worried about with C API calls.  I
> don't care if they never return, which is already possible since it
> could invoke some Python code that goes into an infinite loop.  I am
> worried about a C API call that itself never returns even though one
> of its parents does.

Shure. It does return, but it might not have done its expected
work. Instead it tells you that some work needs to be done.

> I am worried, as Christian explained, about a C
> API call that receives the "unwind token" when it isn't expecting it.

This can never happen. All those functions a new functions. All old
functions do what they tell to do.

> I do not understand how we keep Python's simple, clean C API and also
> support continuations.  I have been waiting for the PEP because I hope
> it will explain this issue.

This is a different issue. Whether we support continuations or
not, this doesn't affect anything else but ceval.c and my modules.

>   SM> I can't help but think, "wow, microthreads sound like they're
>   SM> very efficient and offer a real chance of providing portable
>   SM> threading for Python".  The route to mainstream acceptance of
>   SM> stackless and realization of this thought will be through a PEP.
>   SM> I wouldn't give up at this point.
> Indeed, fast and efficient user-level threads seem like a fine idea.
> I do not understand, again, how stackless + continuations is required
> to implement them.  Just recently wrote: "Continuations aren't even
> needed to do full coroutining and uthreading."  Is even stackless
> required?  I hope the PEP will explain this requirement.

Stackless *is* required, or something similar that can unwind
the C stack.
If you don't expose frames as first-class callable objects, then
you don't need the machinery of continuationmodule.
Implementing coroutines directly on frames is exactly what Just
did. Making frames continuation-proof is an extra exercise that
doesn't harm.

> While we're going for a full disclosure of things I don't understand
> :-), I hope someone will explain why the continuation interface is so
> much more complicated than call/cc.  If Python were to adopt a
> continuation interface, it would seem desirable to use the same
> interface as Scheme and ML, two languages with long experience using
> continuations (mostly to implement threads and exceptions).

Writing a call/cc on top of continuationmodule is about three
lines of Python code.
It just doesn't make so much sense. When SLP was developed,
there was no garbage collector, so passing continuations explicitly
was very likely to create circles.
Without lexical scoping, as in Scheme, call/cc is of much
less use in Python.

import continuation
def callcc(func, *args, **kw):
    return apply(func, (continuation.caller())+args, kw)

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 mailing list