[Python-Dev] PEP 492: async/await in Python; version 4
greg.ewing at canterbury.ac.nz
Wed May 6 10:20:54 CEST 2015
Paul Moore wrote:
>>What about Greg Ewing's example?
> 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
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
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.
More information about the Python-Dev