Jeremy Hylton discourseth: > > 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? This point is particularly worrisome to me because of a common pattern I see in my own Python development work. I'll define a class which is parameterized with some callbacks. Sometimes, when profiling reveals the need, I'll move these classes to C. If the client of the class is using continuations via its callbacks, it may suddenly break. This seems a step back in the modularity I can count on in my program components. ..and I say this as a long-time, die-hard Schemer. :) I definitely pine for micro-threads in some of my application domains though. Eric
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