> On Mar 25, 2019, at 8:01 PM, Guido van Rossum <gu...@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.
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.
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.
Yury
_______________________________________________
Async-sig mailing list
Async-sig@python.org
https://mail.python.org/mailman/listinfo/async-sig
Code of Conduct: https://www.python.org/psf/codeofconduct/
