[Async-sig] A possible tiny step towards event loop interoperability

[Ben Darnell]

I think this could be useful, but's answering the question of "what
coroutine runner is this", not "what event loop is this". It's already
possible to stack one event loop on top of another so that the question of
event loop is ambiguous, but any `async def` function or other coroutine
has exactly one coroutine runner. The identity of the coroutine runner
matters more in practice than the event loop (PEP 484 has standardized the
event loop interface but left coroutine runners unspecified). For more on
this see https://github.com/tornadoweb/tornado/issues/1493 (in which
differences between coroutine runners became an issue in the context of the
event loop integration between Tornado and asyncio), and
https://github.com/tornadoweb/tornado/pull/1716 (in which asyncio.sleep
relies on certain behavior of the asyncio coroutine runner that prevents
its use in the tornado coroutine runner).

-Ben

On Fri, Jun 3, 2016 at 6:26 PM, Nathaniel Smith <njs at pobox.com> wrote:

> Convincing everyone to agree on a single event loop API sounds hard.
>
> But maybe it would be useful to start with a baby step of defining a
> standard way for a coroutine to ask the event loop who it is, e.g.
>
>   await what_event_loop_is_this()
>     -> "asyncio"
>     -> "curio"
>     -> ...
>
> ?
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> _______________________________________________
> Async-sig mailing list
> Async-sig at python.org
> https://mail.python.org/mailman/listinfo/async-sig
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20160603/6fe73240/attachment-0001.html>