[Python-Dev] PEP 492: async/await in Python; version 4

[Greg Ewing]

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