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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
