<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 26, 2019, at 11:56 AM, Yury Selivanov <<a href="mailto:yselivanov@gmail.com" class="">yselivanov@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 25, 2019, at 8:01 PM, Guido van Rossum <<a href="mailto:guido@python.org" class="">guido@python.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">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" class=""></div><br class="Apple-interchange-newline"></div></blockquote></div><br class=""><div class=""><br class=""></div><div class="">I think that if we implement this feature behind a flag then some libraries will start requiring that flag to be set. Which will inevitably lead us to a situation where it's impossible to use asyncio without the flag. Therefore I suppose we should either just implement this behaviour by default or defer this to 3.9 or later.</div></div></div></blockquote><div><br class=""></div><div>How do you feel about my proposal of making the "flag" be simply an argument to run_until_complete? If what you really want to do is start a task or await a future, you should get notified that you're reentrantly blocking; but if you're sure, just pass the arg and be on your way.</div><div><br class=""></div><div>If it's a "flag" like an env var or some kind of global switch, then I totally agree with you.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">I myself am -1 on making 'run_until_complete()' reentrant. The separation of async/await code and blocking code is painful enough to some people, introducing another "hybrid" mode will ultimately do more damage than good. E.g. it's hard to reason about this even for me: I simply don't know if I can make uvloop (or asyncio) fully reentrant.</div></div></div></blockquote><div><br class=""></div><div>If uvloop has problems with global state that prevent reentrancy, fine - for the use-cases where you're doing this, you already kind of implicitly don't care about performance; someone can instantiate their own, safe loop. (If you can't do this with asyncio though I kinda wonder what's going on.)</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">In case of Jupyter I don't think it's a good idea for them to advertise nest_asyncio. IMHO the right approach would be to encourage library developers to expose async/await APIs and teach Jupyter users to "await" on async code directly.</div></div></div></blockquote><div><br class=""></div><div>✨💖✨</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">The linked Jupyter issue (<a href="https://github.com/jupyter/notebook/issues/3397" class="">https://github.com/jupyter/notebook/issues/3397</a>) is a good example: someone tries to call "asyncio.get_event_loop().run_until_complete(foo())" and the call fails. Instead of recommending to use "nest_asyncio", Jupyter REPL could simply catch the error and suggest the user to await "foo()". We can make that slightly easier by changing the exception type from RuntimeError to NestedAsyncioLoopError. In other words, in the Jupyters case, I think it's a UI/UX problem, not an asyncio problem.</div></div></blockquote><br class=""></div><div>So, you may not be able to `await` right now, today, from a cell, given that that needs some additional support. But you can create_task just fine, right? Making await-with-no-indentation work seamlessly would be beautiful but I don't think we need to wait for that modification to get made in order to enjoy the benefits of proper asynchrony.</div><div><br class=""></div><div>-g</div><br class=""></body></html>