"Phillip J. Eby" <pje at telecommunity.com> wrote: > > I believe that this may be an unrealistic goal, even though I have done > something rather similar myself. There is a myriad assortment of policy > issues you'll have to swim upstream past, just to get to the mechanism > issues. For example, Twisted assumes its reactor is an interpreter-global, > maybe even process-global event loop, whereas asyncore and peak.events > allow multiple event loops. > > I've dabbled in integrating Twisted and peak.events, such that code written > for peak.events can run with or without Twisted, and such that an > asynchronous server can be run synchronously. So, it's certainly possible > to do something like what you're describing, but I'm not sure it's worth > the effort versus someone simply installing PEAK and/or Twisted. Since most people are saying that this would be ugly (at least in the realm of Twisted), I'll take back the offer. > Now, if the Python standard library included a lightweight task switching > facility akin to Armin's greenlets, it might be more practical to include > asynchronous communications facilities in the stdlib. Essentially, one > could implement a set of communication primitives that task-switched to a > global scheduler, or one could supply the scheduler as part of the calls, > or provide the primitives as methods of a scheduler, etc. This would > bypass most of the architectural policy issues. Re: greenlets If someone were ambitious, one could write an implementation of greenlets using standard threads for platforms without an optimized greenlets implementation. - Josiah
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