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

[Norman Shelley (rrdn60)]

Jeremy Hylton wrote:

> [Changed discussion list from general python-list to specific
> stackless.]
>
> >>>>> "GvR" == Guido van Rossum <guido@python.org> writes:
>
>   >> I have put up 6 pages of information about stackless at
>   >> http://www.mcmillan-inc.com/stackless.html
>
>   GvR> Gordon, thanks for doing this.  I still have a review of
>   GvR> Stackless on my TODO list.  It takes a serious chunk of my time
>   GvR> to do it justice, and this continues to be a problem, but the
>   GvR> existience of your overview certainly helps.  I still think
>   GvR> that the current Stackless implementation is too complex, and
>   GvR> that continuations aren't worth the insanity they seem to
>   GvR> require (or cause :-), but that microthreads and coroutines
>   GvR> *are* worth having and that something not completely unlike
>   GvR> Stackless will be one day the way to get there...
>
> I tend to agree with you, Guido.  I think we would do well to
> purposefully omit continuations from the Python language.  There seems
> to be little need for a facility to implement arbitrary control
> structures in Python.  If Python support coroutines and microthreads,
> I am not sure what else would be needed.
>
> It would be very helpful if the PEPs on Stackless could address this
> issue.  One way to address it is to ask these questions: What new
> control structures do users want in Python?

This kind of question/thought disturbs me.  It presumes we can determine
apriori all the ways one might wish to use the features that Stackless
provides.  Closing off or bounding innovation just because we can't
answer the question as to how it will be used will just cause future
forks in Python or promote or  non-Python choices.

> How best can they be
> implemented?  Are continuations necessary to implement them or are
> there other options?
>
> The sort of implementation complexity that I worry about with
> Stackless is, e.g. clean interaction with the C stack.  If a Python C
> API call is made that pushes a C stack frame, e.g. PyObject_Compare,
> then a continuation stored before that call can no longer be invokved.
> The problem is that continuations break the notion a C API call will
> always return an answer; they create a situation in which the C call
> that is made should never return, because control is transferred to
> the continuation.  I assume Stackless raises an error in this case,
> but this seems pretty messy: How do we right a language spec that
> explains when an error will occur without appealing to the
> language implementation?
>
> Jeremy
>
> _______________________________________________
> Stackless mailing list
> Stackless@starship.python.net
> http://starship.python.net/mailman/listinfo/stackless