Mailman 3 - Async-sig

PEP: asynchronous generators
by Yury Selivanov 12 Aug '16

12 Aug '16

Hi, I have been working on a PEP to add asynchronous generators to Python. The PEP is now ready for a review. It would be great to hear some initial feedback from async-sig, before I post it to python-ideas. I have a complete and working reference implementation of everything that PEP proposes here: https://github.com/1st1/cpython/tree/async_gen PEP: XXX Title: Asynchronous Generators Version: $Revision$ Last-Modified: $Date$ Author: Yury Selivanov <yury(a)magic.io> Discussions-To: <python-dev(a)python.org> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 28-Jul-2016 Python-Version: 3.6 Post-History: Abstract ======== PEP 492 introduced support for native coroutines and ``async``/``await`` syntax to Python 3.5. It is proposed here to extend Python's asynchronous capabilities by adding support for *asynchronous generators*. Rationale and Goals =================== Regular generators (introduced in PEP 255) enabled an elegant way of writing complex *data producers* and have them behave like an iterator. However, currently there is no equivalent concept for the *asynchronous iteration protocol* (``async for``). This makes writing asynchronous data producers unnecessarily complex, as one must define a class that implements ``__aiter__`` to be able to use it in an ``async for`` statement. Essentially, the goals and rationale for PEP 255, applied to the asynchronous execution case, hold true for this proposal as well. Performance is an additional point for this proposal: in our testing of the reference implementation, asynchronous generators are *2x* faster than an equivalent implemented as an asynchronous iterator. As an illustration of the code quality improvement, consider the following class that prints numbers with a given delay once iterated:: class ticker: """Print numbers from 0 to `to` every `delay` seconds.""" def __init__(self, delay, to): self.delay = delay self.i = 0 self.to = to def __aiter__(self): return self async def __anext__(self): i = self.i if i >= self.to: raise StopAsyncIteration self.i += 1 if i: await asyncio.sleep(self.delay) return i The same can be implemented as a much simpler asynchronous generator:: async def ticker(delay, to): """Print numbers from 0 to `to` every `delay` seconds.""" i = 0 while i < to: yield i i += 1 await asyncio.sleep(delay) Specification ============= This proposal introduces the concept of *asynchronous generators* to Python. This specification presumes knowledge of the implementation of generators and coroutines in Python (PEP 342, PEP 380 and PEP 492). Asynchronous Generators ----------------------- A Python *generator* is any function containing one or more ``yield`` expressions:: def func(): # a function return def genfunc(): # a generator function yield We propose to use the same approach to define *asynchronous generators*:: async def coro(): # a coroutine function await smth() async def asyncgen(): # an asynchronous generator function await smth() yield val The result of calling an *asynchronous generator function* is an *asynchronous generator object*, which implements the asynchronous iteration protocol defined in PEP 492. It is a ``SyntaxError`` to have a non-empty ``return`` statement in an asynchronous generator. Support for Asynchronous Iteration Protocol ------------------------------------------- The protocol requires two special methods to be implemented: 1. An ``__aiter__`` method returning an *asynchronous iterator*. 2. An ``__anext__`` method returning an *awaitable* object, which uses ``StopIteration`` exception to "yield" values, and ``StopAsyncIteration`` exception to signal the end of the iteration. Asynchronous generators define both of these methods:: async def genfunc(): yield 1 yield 2 gen = genfunc() assert gen.__aiter__() is gen assert await gen.__anext__() == 1 assert await gen.__anext__() == 2 with assertRaises(StopAsyncIteration): await gen.__anext__() Finalization ------------ PEP 492 requires an event loop or a scheduler to run coroutines. Because asynchronous generators are meant to be used from coroutines, they also require an event loop to run and finalize them. Asynchronous generators can have ``try..finally`` blocks, as well as ``async with``. It is important to provide a guarantee that, even when partially iterated, and then garbage collected, generators can be safely finalized. For example:: async def square_series(con, to): async with con.transaction(): cursor = con.cursor( 'SELECT generate_series(0, $1) AS i', to) async for row in cursor: yield row['i'] ** 2 async for i in square_series(con, 100): if i == 100: break The above code defines an asynchronous generator that uses ``async with`` to iterate over a database cursor in a transaction. The generator is then iterated over with ``async for``, which interrupts the iteration at some point. The ``square_series()`` generator will then be garbage collected, and without a mechanism to asynchronously close the generator, Python interpreter would not be able to do anything. To solve this problem we propose to do the following: 1. Implement an ``aclose`` method on asynchronous generators returning a special *awaitable*. When awaited it throws a ``GeneratorExit`` into the suspended generator and iterates over it until either a ``GeneratorExit`` or a ``StopAsyncIteration`` occur. This is very similar to what the ``close()`` method does to regular Python generators, except that an event loop is required to execute ``aclose()``. 2. Raise a ``RuntimeError``, when an asynchronous generator executes a ``yield`` expression in its ``finally`` block (using ``await`` is fine, though):: async def gen(): try: yield finally: yield # Cannot use 'yield' await asyncio.sleep(1) # Can use 'await' 3. Add two new methods to the ``sys`` module: ``set_asyncgen_finalizer`` and ``get_asyncgen_finalizer``. The idea behind ``sys.set_asyncgen_finalizer`` is to allow event loops to handle generators finalization, so that the end user does not need to care about the finalization problem, and it just works. When an asynchronous generator is iterated for the first time, it stores a reference to the current finalizer. If there is none, a ``RuntimeError`` is raised. This provides a strong guarantee that every asynchronous generator object will always have a finalizer installed by the correct event loop. When an asynchronous generator is about to be garbage collected, it calls its cached finalizer. The assumption is that the finalizer will schedule an ``aclose()`` call with the loop that was active when the iteration started. For instance, here is how asyncio can be modified to allow safe finalization of asynchronous generators:: # asyncio/base_events.py class BaseEventLoop: def run_forever(self): ... old_finalizer = sys.get_asyncgen_finalizer() sys.set_asyncgen_finalizer(self._finalize_asyncgen) try: ... finally: sys.set_asyncgen_finalizer(old_finalizer) ... def _finalize_asyncgen(self, gen): self.create_task(gen.aclose()) ``sys.set_asyncgen_finalizer`` is thread-specific, so several event loops running in parallel threads can use it safely. Asynchronous Generator Object ----------------------------- The object is modeled after the standard Python generator object. Essentially, the behaviour of asynchronous generators is designed to replicate the behaviour of synchronous generators, with the only difference in that the API is asynchronous. The following methods and properties are defined: 1. ``agen.__aiter__()``: Returns ``agen``. 2. ``agen.__anext__()``: Returns an *awaitable*, that performs one asynchronous generator iteration when awaited. 3. ``agen.anext(val)``: Returns an *awaitable*, that pushes the ``val`` object in the ``agen`` generator. When the ``agen`` has not yet been iterated, ``val`` must be ``None``. Example:: async def gen(): await asyncio.sleep(0.1) v = yield 42 print(v) await asyncio.sleep(0.1) g = gen() await g.send(None) # Will return 42 await g.send('hello') # Will print 'hello' and # raise StopAsyncIteration # (after sleeping for 0.1 seconds) 4. ``agen.athrow(typ, [val, [tb]])``: Returns an *awaitable*, that throws an exception into the ``agen`` generator. Example:: async def gen(): try: await asyncio.sleep(0.1) yield 'hello' except ZeroDivisionError: await asyncio.sleep(0.2) yield 'world' g = gen() v = await g.asend(None) print(v) # Will print 'hello' after sleeping 0.1s v = await g.athrow(ZeroDivisionError) print(v) # Will print 'world' after sleeping 0.2s 5. ``agen.aclose()``: Returns an *awaitable*, that throws a ``GeneratorExit`` exception into the generator. The *awaitable* can either return a yielded value, if ``agen`` handled the exception, or ``agen`` will be closed and the exception will propagate back to the caller. 6. ``agen.__name__`` and ``agen.__qualname__``: readable and writable name and qualified name attributes. 7. ``agen.ag_await``: The object that ``agen`` is currently awaiting on, or ``None``. 8. ``agen.ag_frame``, ``agen.ag_running``, and ``agen.ag_code``: defined in the same way as similar attributes of standard generators. New Standard Library Functions and Types ---------------------------------------- 1. ``types.AsyncGeneratorType`` -- type of asynchronous generator object. 2. ``sys.set_asyncgen_finalizer()`` and ``sys.get_asyncgen_finalizer()`` methods to set up asynchronous generators finalizers in event loops. 3. ``inspect.isasyncgen()`` and ``inspect.isasyncgenfunction()`` introspection functions. Backwards Compatibility ----------------------- The proposal is fully backwards compatible. In Python 3.5 it is a ``SyntaxError`` to define an ``async def`` function with a ``yield`` expression inside, therefore it's safe to introduce asynchronous generators in 3.6. Performance =========== Regular Generators ------------------ There is no performance degradation for regular generators. The following micro benchmark runs at the same speed on CPython with and without asynchronous generators:: def gen(): i = 0 while i < 100000000: yield i i += 1 list(gen()) Improvements over asynchronous iterators ---------------------------------------- The following micro-benchmark shows that asynchronous generators are about **2x faster** than asynchronous iterators implemented in pure Python: async def agen(): i = 0 while i < N: yield i i += 1 class AIter: def __init__(self): self.i = 0 def __aiter__(self): return self async def __anext__(self): i = self.i if i >= N: raise StopAsyncIteration self.i += 1 return i Design Considerations ===================== ``aiter()`` and ``anext()`` builtins ------------------------------------ Originally PEP 492 defined ``__aiter__`` as a method that should return an *awaitable* object, resulting in an asynchronous iterator. However, in CPython 3.5.2, ``__aiter__`` was redefined to return asynchronous iterators directly. To avoid breaking backwards compatibility, it was decided that Python 3.6 will support both ways: ``__aiter__`` can still return an *awaitable* with a ``DeprecationWarning`` being issued. Because of this dual nature of ``__aiter__`` in Python 3.6, we cannot add a synchronous implementation of ``aiter()`` built-in. Therefore, it is proposed to wait until Python 3.7. Asynchronous list/dict/set comprehensions ----------------------------------------- Syntax for asynchronous comprehensions is unrelated to the asynchronous generators machinery, and should be considered in a separate PEP. Asynchronous ``yield from`` --------------------------- While it is theoretically possible to implement ``yield from`` support for asynchronous generators, it would require a serious redesign of the generator implementation. ``yield from`` is also less critical for asynchronous generators, since there is no need provide a mechanism of implementing another coroutines protocol on top of coroutines. To compose asynchronous generators a simple ``async for`` loop can be used:: async def g1(): yield 1 yield 2 async def g2(): async for v in g1(): yield v Why the ``asend`` and ``athrow`` methods are necessary ------------------------------------------------------ They make it possible to implement concepts similar to ``contextlib.contextmanager`` using asynchronous generators. For instance, with the proposed design, it is possible to implement the following pattern:: @async_context_manager async def ctx(): await open() try: yield finally: await close() async with ctx(): await ... Another reason is that it is possible to push data and throw exceptions into asynchronous generators using the object returned from ``__anext__`` object, but it is hard to do that correctly. Adding explicit ``asend`` and ``athrow`` will pave a safe way to accomplish that. Example ======= A working example with the current reference implementation (will print numbers from 0 to 9 with one second delay):: async def ticker(delay, to): i = 0 while i < to: yield i i += 1 await asyncio.sleep(delay) async def run(): async for i in ticker(1, 10): print(i) import asyncio loop = asyncio.get_event_loop() try: loop.run_until_complete(run()) finally: loop.close() Implementation ============== The complete reference implementation is available at [1]_. References ========== .. [1] https://github.com/1st1/cpython/tree/async_gen Copyright ========= This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: Thank you! Yury

11 47

Warts both in asyncio way and greenlet-based approach
by Andrew Svetlov 05 Aug '16

05 Aug '16

Long story short: in async world every IO library should use asyncio. Unfortunately for the most popular libraries (requests, django, flask, sqlalchemy etc.) it's impossible to rewrite the code keeping backward compatibility. Much easier to create a new library than rewrite existing one. Regarding to gevent -- please read excellent Glyph's article 'Unyielding': https://glyph.twistedmatrix.com/2014/02/unyielding.html It covers pretty well why explicit yield points are better than implicit ones. Shortly explicit `await`'s give you 'atomic consistency' but using gevent you should expect context switch in every opcode instruction. It's much easier to test cover code with several (ok, many) context switch points. But test covering the code which may switch on every line and several times in the same line is practically impossible. Also my 2 cents. We used gevent. Even in very tiny application (command line client to upload huge files over HTTP, about 1k lines of code) under high load we got reports about gevent hub crashes. Even gevent core (hub is something like asyncio loop) is not 100% stable. Unfortunately we was not able to reproduce the problem by our test suite -- it requires really high load and occurs very rare. Well, the most gevent users can live with that -- gunicorn just restarts dead worker and that's it. But it is the sign for the problem: gevent crashes are extremely hard to debug. P.S. You might keep my writings about gevent as my private opinion, and it is. But from my perspective asyncio based solutions have much more predictable behavior and much more friendly to debug-and-fix problems. -- Thanks, Andrew Svetlov

3 4

Re: [Async-sig] Asynchronous cleanup is a problem
by David Beazley 06 Jul '16

06 Jul '16

Cory wrote: "What’s not entirely clear to me is why we need __aexit__ to *actually* be an async function. The example in curio is socket closure, which seems to be like it absolutely does not need to be awaitable." Curio uses asynchronous context managers for much more than closing sockets (which frankly is the least interesting thing). For example, they're used extensively with synchronization primitives such as Locks, Semaphores, Events, Queues, and other such things. The ability to use coroutines in the __aexit__() method is an essential part of these primitives because it allows task scheduling decisions to be made in conjunction with synchronization events such as lock releases. For example, you can implement fair-locking or various forms of priority scheduling. Curio also uses asynchronous context managers for timeouts and other related functionality where coroutines have to be used in __aexit__. I would expect coroutines in __aexit__ to also be useful in more advanced contexts such as working with databases, dealing with transactions, and other kinds of processing where asynchronous I/O might be involved. As such, I think it's pretty useful to allow coroutines in __aexit__() and would be strongly opposed to restricting it. -Dave

5 12

Asynchronous cleanup is a problem
by Nathaniel Smith 06 Jul '16

06 Jul '16

So here's an interesting issue I just discovered while experimenting with async generators. It caught me by surprise, anyway. Maybe this was already obvious to everyone else. But I wanted to get some more perspectives. Starting axiom: async functions / async generators need to be prepared for the case where they get garbage collected before being run to completion, because, well... this is a thing that can happen. Currently, the way garbage collection is handled is that their __del__ method calls their .close() method, which does something like: class GeneratorType: ... def close(self): try: self.throw(GeneratorExit) except GeneratorExit, StopIteration: return # it worked, all is good except: raise # double-fault, propagate else: raise RuntimeError("generator ignored GeneratorExit") (see PEP 342). So far, so obvious -- an async function that gets a GeneratorExit has to propagate that exception immediately. This is a regular method, not an async method, because it Dismaying conclusion: inside an async function / async generator, finally: blocks must never yield (and neither can __aexit__ callbacks), because they might be invoked during garbage collection. For async functions this is... arguably a problem but not super urgent, because async functions rarely get garbage collected without being run to completion. For async generators it's a much bigger problem. There's some more discussion, and a first sketch at conventions we might want to use for handling this, here: https://github.com/dabeaz/curio/issues/70 -n -- Nathaniel J. Smith -- https://vorpus.org

5 4

async executors
by Christoph Groth 13 Jun '16

13 Jun '16

Hi, A few days ago I posted a message [1] on python-ideas to which no one replied except Brett who suggested re-posting it here, which I do now. The following is a complete rewrite/update of the original message. I promise: I will stop the spamming if no one replies this time! Async programming with executors seems to be a useful approach for number-crunching problems where the main algorithm (the one launching the futures) is quite complicated and possibly concurrent, but light enough to run on a single core (the heavy lifting is done “inside” the futures). This use case is addressed by asyncio's run_in_executor that uses the executors provided by the concurrent.futures package. There is, however, a lot of duplication of functionality between concurrent.futures and asyncio. (The main difference is that concurrent.futures relies on threading and locks.) If one is going to use concurrent.futures only from coroutines that run under the control of the asyncio event loop, it should be possible to replace the concurrent.futures executors by async versions of them. Why could such an async executor be interesting? • It can be a lot simpler (and thus easier to understand and extend) because it builds on top of asyncio. There have been already discussions on unifying the Future type from concurrent.futures with that of asyncio [2]. • Performance is better, especially when many worker processes are involved, because of the simpler code that uses less locking (the only locking that remains is inside the multiprocessing module). As far as I can see the original concurrent.futures.ProcessPoolExecutor has no advantage when used in asyncio-based programs except when some coroutine blocks for long enough for the call queue to become empty. (But hey, async programming is about non-blocking coroutines!) Are there other possible advantages or disadvantages? Based on concurrent.futures.ProcessPoolExecutor, I’ve made a proof-of-concept implementation [3] that demonstrates that the idea works. (There have been some improvements compared to the version that I posted on python-ideas.) Christoph PS. I would be grateful if any asyncio experts could have a look at the part of the main loop of the process management coroutine where the coroutine awaits new data [4]. Currently, I am using an asyncio.Event that is set by a callback via asyncio’s add_reader(). Is this the most natural way to do it currently? I’m particularly puzzled by the fact that reader.poll(0) is not always true after the event has been set. If there is no better way to combine asyncio and multiprocessing.Process, perhaps this is a thing that could be improved in a future version of the Python stdlib? [1] http://thread.gmane.org/gmane.comp.python.ideas/40709 [2] http://thread.gmane.org/gmane.comp.python.ideas/24551/focus=24557 [3] https://gitlab.kwant-project.org/cwg/aexecutor [4] https://gitlab.kwant-project.org/cwg/aexecutor/blob/9290504e779c543d9ee93ad…

3 5

Re: [Async-sig] asyncio.timeout() is not portable
by Nathaniel Smith 12 Jun '16

12 Jun '16

On Jun 6, 2016 10:19 AM, "Yury Selivanov" <yselivanov(a)gmail.com> wrote: > > > > On Jun 5, 2016, at 11:56 AM, Ben Darnell <ben(a)bendarnell.com> wrote: > > > > It has come to my attention ( https://github.com/KeepSafe/aiohttp/issues/877) that Python 3.5.2 (!) introduced a new context manager asyncio.timeout, which attaches a timeout to the current asyncio.Task. Any library or application that uses this feature will not be portable to other coroutine runners. > > > > with asyncio.timeout(1): > > result = await aiohttp.get('http://www.example.com') > > > > It's difficult to make this interface portable. We'd need to introduce a global thread-specific object that all of the coroutine runners could register the current task on, and define an interface that asyncio.timeout would call on that object to set the timeout. We could get rid of the global if the context manager used `async with` instead of `with`, since that would give us a way to communicate with the coroutine runner directly, but the net result is still that each runner needs to implement hooks for this feature (the hooks may or may not be generalizable to other features in the future). > > We’ve discussed this and decided that we should revert asyncio.Timeout from 3.5.2. I’ll do that later today. This is tangential and somewhat irrelevant given the above, but since I'm not sure where else to put it: having thought about this issue a bit more last night, I also think that it's important that the timeout manager (if/when it's reintroduced) should inject a meaningful exception like TimeoutError, and it should be legal for the coroutine to catch this and continue. This is in contrast to the one that's currently being reverted, which uses the task cancellation feature and is indistinguishable from any other use of the task cancellation feature. -n

4 5

asyncio.timeout() is not portable
by Ben Darnell 12 Jun '16

12 Jun '16

It has come to my attention (https://github.com/KeepSafe/aiohttp/issues/877) that Python 3.5.2 (!) introduced a new context manager asyncio.timeout, which attaches a timeout to the current asyncio.Task. Any library or application that uses this feature will not be portable to other coroutine runners. with asyncio.timeout(1): result = await aiohttp.get('http://www.example.com') It's difficult to make this interface portable. We'd need to introduce a global thread-specific object that all of the coroutine runners could register the current task on, and define an interface that asyncio.timeout would call on that object to set the timeout. We could get rid of the global if the context manager used `async with` instead of `with`, since that would give us a way to communicate with the coroutine runner directly, but the net result is still that each runner needs to implement hooks for this feature (the hooks may or may not be generalizable to other features in the future). If our goal is portability across coroutine runners, then asyncio.timeout() needs to go back to the drawing board. If the goal is to extend asyncio.Task to be the one true coroutine runner then we could leave it as-is. For comparison, Tornado's equivalent to asyncio.timeout is tornado.gen.with_timeout(), and it has no special interactions with the coroutine runner: result = await with_timeout(timedelta(seconds=1), convert_yielded(aiohttp.get("http://www.example.com"))) (The convert_yielded call won't be needed in the next release of Tornado. The use of timedelta is because Tornado prefers absolute deadlines instead of relative timeouts, so that's how plain numbers are interpreted). -Ben

5 7

asyncio <-> twisted interoperability
by Yury Selivanov 08 Jun '16

08 Jun '16

During the asyncio open space a few days ago we had a number of important questions raised, including Twisted/asyncio interop. I’d like to start the discussion of a few related things: 1. key difference between a Deferred and a Future; 2. make Deferred objects compatible with asyncio code; 3. overall strategy to make Twisted code compatible with asyncio code. In detail: 1. Unlike Futures, Deferred objects know nothing about the event loop. Deferred calls its callbacks directly, while Future uses ‘loop.call_soon’ to ensure fair scheduling. 2. I see two issues with Deferred/Future compatibility: 2.1. There should be a way for Deferred objects to get the currently running event loop reliably. There is a pending PR to add the new ‘asyncio.get_running_loop’ function. If we land it in 3.5.2, Deferred object will be able to get the currently running event loop and schedule callbacks in a fair fashion, similarly to Futures. 2.2. asyncio uses ‘isinstance(o, Future)’ calls in many key places, such as ‘asyncio.ensure_future’ and in the Task class. The latter makes it impossible for anything but Future and coroutines to be awaitable in asyncio code. We have two options to fix this: make Future an instance of ABCMeta, or introduce a new protocol for Future-like objects. The former option will not be considered because it makes isinstance calls much slower. As for the second option — a protocol for Future-like objects — I propose to add a new dunder attribute ‘__asyncio_future__ = True’ to asyncio.Future class, and replace all ‘isinstance(o, Future)’ calls with ‘hasattr(o, “__asyncio_future__”)’ checks. (2.1) and (2.2) should make it possible for Twisted to make Deferred objects fully compatible with asyncio code. Glyph and Amber, please confirm this. 3. I’ve been on Amber’s talk about Twisted and asyncio, and wanted to share my ideas on how Twisted should approach compatibility with asyncio and async/await syntax: - I don’t think we need ‘twisted.deferredCoroutine’ decorator — that will make async/await a lot slower. Instead, Twisted should follow asyncio and create an alternative, tailored for Twisted, implementation of ‘asyncio.Task’, along with ‘ensure_deferred’ and/or ‘create_task’ APIs. This way users can create Deferreds for coroutines only when they need it. - ‘ensure_deferred’ could also accept instances of ‘asyncio.Future’, and wrap them in a Deferred object. This should make it possible to re-use asyncio-specific code in Twisted code. Thoughts? Thanks, Yury

6 18

Re: [Async-sig] async executors
by Nathaniel Smith 06 Jun '16

06 Jun '16

On Jun 6, 2016 5:37 AM, "Christoph Groth" <christoph(a)grothesque.org> wrote: > [...] > Async programming with executors seems to be a useful approach for number-crunching problems where the main algorithm (the one launching the futures) is quite complicated and possibly concurrent, but light enough to run on a single core (the heavy lifting is done “inside” the futures). > > This use case is addressed by asyncio's run_in_executor that uses the executors provided by the concurrent.futures package. There is, however, a lot of duplication of functionality between concurrent.futures and asyncio. (The main difference is that concurrent.futures relies on threading and locks.) If one is going to use concurrent.futures only from coroutines that run under the control of the asyncio event loop, it should be possible to replace the concurrent.futures executors by async versions of them. Sounds like an interesting project :-) FYI, the latest versions of curio also have their own thread/process pool implementations that replace concurrent.futures, I think for similar reasons to the ones you allude to: http://curio.readthedocs.io/en/latest/reference.html#performing-external-wo… There are certainly reasons you might prefer to use asyncio instead of curio, but if you're implementing such a thing on asyncio then curio's implementation and semantics might be interesting for reference. -n

1 0

A possible tiny step towards event loop interoperability
by Nathaniel Smith 04 Jun '16

04 Jun '16

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

7 21