<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 3, 2016 at 10:40 PM, Yury Selivanov <span dir="ltr"><<a href="mailto:yselivanov@gmail.com" target="_blank">yselivanov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class=""><br>
> On Jun 3, 2016, at 8:14 PM, Ben Darnell <<a href="mailto:ben@bendarnell.com">ben@bendarnell.com</a>> wrote:<br>
><br>
> 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).<br>
<br>
</span>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?<br></blockquote><div><br></div><div>I was thinking it would just return a string like "asyncio", but returning the Task itself could be useful too.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<span class=""><br>
> For more on this see <a href="https://github.com/tornadoweb/tornado/issues/1493" rel="noreferrer" target="_blank">https://github.com/tornadoweb/tornado/issues/1493</a> (in which differences between coroutine runners became an issue in the context of the event loop integration between Tornado and asyncio), and <a href="https://github.com/tornadoweb/tornado/pull/1716" rel="noreferrer" target="_blank">https://github.com/tornadoweb/tornado/pull/1716</a> (in which asyncio.sleep relies on certain behavior of the asyncio coroutine runner that prevents its use in the tornado coroutine runner).<br>
<br>
</span>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?<br><br></blockquote><div><br></div><div>Neither of these are concrete issues that would be solved by exposing the coroutine runner, but they're an example of how the coroutine runner often matters more to the application than the event loop implementation (which you can already get with type(asyncio.get_event_loop())). A better example is the difference between tornado.gen.multi and asyncio.gather (<a href="https://github.com/tornadoweb/tornado/issues/1684">https://github.com/tornadoweb/tornado/issues/1684</a>). If the coroutine runner is asyncio, then asyncio.gather must be used and tornado.gen.multi won't work. If the coroutine runner is Tornado, then tornado.gen.multi is preferred; asyncio.gather will not work if any of the coroutines passed to it assume the tornado coroutine runner. </div><div><br></div><div>-Ben</div></div><br></div></div>