<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 25, 2019 at 5:11 PM Ben Darnell <<a href="mailto:ben@bendarnell.com">ben@bendarnell.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, Mar 25, 2019 at 8:02 PM Guido van Rossum <<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr"><br></div></div></div><div>Given PBP, I wonder if we should just relent and have a configurable flag (off by default) to allow nested loop invocations (both the same loop and a different loop).<br clear="all"></div><div dir="ltr"><br></div></div></blockquote><div><br></div><div>Allowing reentrant calls to the same loop is not a good idea IMO. At best, you'll need to carefully ensure that the event loop and task implementations are themselves reentrancy-safe (including the C accelerators and third parties like uvloop?), and then it just invites subtle issues in the applications built on top of it. I don't think there's a good reason to allow or support this (and nest_asyncio should be heavily discouraged). I do, however, think that PBP is a good enough reason to allow opt-in use of multiple event loops nested inside each other (maybe something on the EventLoopPolicy for configuration?).  <br></div></div></div></blockquote><div><br></div><div>Well, at least I am not alone in being very wary about nest_asyncio (and disappointed that Jupyter recommends it).</div><div><br></div><div>It would certainly require carefully ensuring reentrancy of the asyncio implementation. I guess that's one reason why nest_asyncio disables the C accelerators and doesn't work with uvloop. Regarding reentrancy of applications, I think that would be somewhat limited -- the critical section I showed in my first message in this thread would still be safe, as long as the queue implementation chooses not to call out to code that uses run_until_complete(). We might need a convention to document whether something runs an event loop (in the strict asyncio philosophy this convention is `async def` of course :-).</div><div><br></div><div>I guess calling out to a different event loop is no worse than calling out to requests -- I consider both strong violations of asyncio's ideals.<br></div></div><br>-- <br><div dir="ltr" class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div></div>