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/