Paul Moore wrote:
What about Greg Ewing's example? http://www.cosc.canterbury.ac.nz/greg.ewing/python/yield-from/yf_current/Exa...
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.