[Python-Dev] Using async/await in place of yield expression

[Guido van Rossum]

On Mon, Nov 27, 2017 at 1:12 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Mon, 27 Nov 2017 00:41:55 -0800
> Nathaniel Smith <njs at pobox.com> wrote:
> >
> > Since most libraries assume that they control both __await__ and the
> > coroutine runner, they don't tend to give great error messages here
> > (though trio does [2] ;-)). I think this is also why the asyncio docs
> > don't talk about this. I guess in asyncio's case it is technically a
> > semi-public API because you need to know how it works if you're the
> > author of a library like tornado or twisted that wants to integrate
> > with asyncio. But most people aren't the authors of tornado or
> > twisted, and the ones who are already know how this works, so the lack
> > of docs isn't a huge deal in practice...
>
> This does seem to mean that it can be difficult to provide a __await__
> method that works with different coroutine runners, though.  For
> example, Tornado Futures implement __await__ for compatibility with the
> asyncio event loop.  But what if Tornado wants to make its Future class
> compatible with an event loop that requires a different __await__
> convention?
>

Someone would have to write a PEP proposing a standard interoperability API
for event loops.

There is already such a PEP (PEP 3156, which standardized the asyncio event
loop, including the interop API) but curio and trio intentionally set out
to invent their own conventions. At least asyncio has an API that allows
overriding the factory for Futures, so if someone comes up with a Future
that is interoperable between asyncio and curio, for example, it might be
possible. But likely curio would have to be modified somewhat too.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171127/a6115aaf/attachment.html>