[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? 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4