Paul Moore wrote: >>What about Greg Ewing's example? >>http://www.cosc.canterbury.ac.nz/greg.ewing/python/yield-from/yf_current/Examples/Scheduler/scheduler.txt > > That doesn't cover any of the higher level abstractions like tasks or > futures (at least not by those names or with those interfaces). Because a minimal event loop doesn't *need* those. In my little scheduler, a "task" is nothing more than a yield-frommable object sitting on a queue of things to be run. There is no need to wrap it in another object. And there's really no need for the concept of a "future" at all, except maybe at the boundary between generator-based async code and other things that are based on callbacks. Even then, a "future" is really just "an object that can be passed to yield-from". There is no need for a concrete Future class, it's just a protocol. > And I > don't see where the PEP 492 additions would fit in (OK, "replace yield > from with await" is part of it, but I don't see the rest). That's really all there is to it. The rest is concerned with catching certain kinds of mistakes, and providing convenient syntax for some patterns of using 'await'. > There's a lot of asyncio > that doesn't seem to me to be IO-related. Specifically the future and > task abstractions. I view those as relevant to "coroutine programming > in Python" because they are referenced in any discussion of coroutines > (you yield from a future, for example). Only because they've been elevated to prominence by asyncio and its documentation, which I regard as unfortunate. When Guido was designing asyncio, I tried very hard to dissuade him from giving futures such a central place in the model. I saw them as an unnecessary concept that would only clutter up people's thinking. Seeing all the confusion now, I'm more convinced than ever that I was right. :-( > In some ways I wish there had been an "asyncio" library that covered > the areas that are fundamentally about IO multiplexing. And a separate > library (just "async", maybe, although that's now a bad idea as it > clashes with a keyword :-)) that covered generic event loop, task and > synchronisation areas. As I said before, I don't think it's really possible to factor an event loop into those kinds of parts. You may be able to factor the *API* that way, but any given implementation has to address all the parts at once. -- Greg
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