On Jun 3, 2016, at 8:14 PM, Ben Darnell <ben@bendarnell.com> wrote:
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).
Right, let’s discuss the hypothetical ‘await what_coroutine_runner_is_this()’. Which, in case of asyncio, would return an instance of the current Task, right?
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).
I’ve read through both of those issues, but I still don’t understand what problem (or how the linked problems) can be solved by getting the current coroutine runner. Could you please provide an example? Thanks, Yury