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

[Jeremy Hylton]

[Changed discussion list from general python-list to specific
stackless.] 

>>>>> "GvR" == Guido van Rossum <guido at 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?  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 at starship.python.net
http://starship.python.net/mailman/listinfo/stackless