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