
asyncio functions works with asyncio-compatible code only, isn't it? For example asyncio.get_event_loop() should return a loop instance which conforms asyncio.AbstractEventLoop ABC. Third-party libraries like aiohttp just cannot work with arbitrary event loop type. They are always require at least *compatible* loop instance. On Fri, Jun 3, 2016 at 4:25 PM Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Jun 3, 2016 at 3:54 PM, Cory Benfield <cory@lukasa.co.uk> wrote:
On 3 Jun 2016, at 15:26, Nathaniel Smith <njs@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" -> ...
How do we ensure that this function is always available in the global
namespace, or alternatively that it’s always available in a *consistent* namespace?
It could go into asyncio, but also we could just document that the function is literally
@types.coroutine def what_event_loop_is_this(): return (yield "WHAT-EVENT-LOOP-IS-THIS")
(actual value subject to bikeshedding -- the point is just that it's some well-known value that the event loop can watch for and which wouldn't be used for anything else.)
-n
-- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ Async-sig mailing list Async-sig@python.org https://mail.python.org/mailman/listinfo/async-sig Code of Conduct: https://www.python.org/psf/codeofconduct/
-- Thanks, Andrew Svetlov