[Async-sig] Inadvertent layering of synchronous code as frameworks adopt asyncio

[Glyph]

> On Mar 26, 2019, at 11:56 AM, Yury Selivanov <yselivanov at gmail.com> wrote:
> 
> 
>> On Mar 25, 2019, at 8:01 PM, Guido van Rossum <guido at python.org <mailto:guido at python.org>> wrote:
>> 
>> 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).
>> 
> 
> 
> 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.

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.

If it's a "flag" like an env var or some kind of global switch, then I totally agree with you.

> 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.

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.)

> 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.

✨💖✨

> The linked Jupyter issue (https://github.com/jupyter/notebook/issues/3397 <https://github.com/jupyter/notebook/issues/3397>) 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.

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.

-g

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20190326/1f374495/attachment.html>