rushing at nightmare.com wrote: > > [list has been quiet, thought I'd liven things up a bit. 8^)] Well, there certainly is enough on the todo list... it's probably the usual "ain't got no time" thing. > I'm not sure if this has been brought up before in other forums, but > has there been discussion of separating the Python and C invocation > stacks, (i.e., removing recursive calls to the intepreter) to > facilitate coroutines or first-class continuations? Wouldn't it be possible to move all the C variables passed to eval_code() via the execution frame ? AFAIK, the frame is generated on every call to eval_code() and thus could also be generated *before* calling it. > One of the biggest barriers to getting others to use asyncore/medusa > is the need to program in continuation-passing-style (callbacks, > callbacks to callbacks, state machines, etc...). Usually there has to > be an overriding requirement for speed/scalability before someone will > even look into it. And even when you do 'get' it, there are limits to > how inside-out your thinking can go. 8^) > > If Python had coroutines/continuations, it would be possible to hide > asyncore-style select()/poll() machinery 'behind the scenes'. I > believe that Concurrent ML does exactly this... > > Other advantages might be restartable exceptions, different threading > models, etc... Don't know if moving the C stack stuff into the frame objects will get you the desired effect: what about other things having state (e.g. connections or files), that are not even touched by this mechanism ? -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: Y2000: 232 days left Business: http://www.lemburg.com/ Python Pages: http://starship.python.net/crew/lemburg/
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