Upstream contribution about nest_asyncio HOT 8 OPEN

At the same time, I don't think his argument:

I understand this will make your code slightly less elegant in some cases, but I think in the end it is for the best if you are required to define an explicit method (declared to be a coroutine)

really applies to the issue we are faced with. It is not a matter of making some code less elegant, but we have no other choice than using nest-asyncio or running another event loop in another thread (or using something like unasync), and none of them are ideal.
Also, his answer is from 2014, maybe core devs would be more inclined to reconsider the issue today?

from nest_asyncio.

There is the original discussion thread here, where the explicit decision is made to not allow nesting. The main objection by GvR is

very hard to debug problems that appeared as very infrequent and hard to predict stack overflows

This is a valid concern and care should be taking to not to exceed the recursion limit (1000 by default). When the recursion does get too deep, the long stack trace makes it very obvious what is happening though.

from nest_asyncio.

Maybe some people are changing their minds about this now: https://bugs.python.org/issue22239#msg398257

from nest_asyncio.

I think nest asyncio breaks a fundamental assumption that in if you don't await, you cannot task switch. Now an await can hide behind a sync call, making it behave similar as multithreaded code (a task switch can occur at 'any' moment). So, I really appreciate this project, but it should be used with caution.

from nest_asyncio.

Good point, although with nest-asyncio asyncio.run(coro) could almost be replaced with await coro, with the particularity that await can now be used even if the function is not async.
It's really in that particular case (the function where asyncio.run is called) that task switching can happen with nest-asyncio, while it cannot without it. But yes it makes it hard to say by just looking if the function is async.

from nest_asyncio.

I went ahead an opened python/cpython#93338. I hope you don't mind @erdewit, and of course if the PR is accepted you should be the author of it.

from nest_asyncio.

That's a great idea @davidbrochart. I think if the asyncio authors do want nesting then it might be easier for them to modify their own code then it is to copy the (simplified) nest_asyncio code over. Probably they'll also want a flag like asyncio.allow_nesting that needs to be explicitly set first by the user, and if not set will keep the current behavior.

from nest_asyncio.

I think if the asyncio authors do want nesting then it might be easier for them to modify their own code then it is to copy the (simplified) nest_asyncio code over.

Yes, also the equivalent changes would need to be made in the C implementation.

Probably they'll also want a flag like asyncio.allow_nesting that needs to be explicitly set first by the user, and if not set will keep the current behavior.

I agree, although it seems difficult to handle the case where two libraries want different behaviors (one wants nesting, the other not).

from nest_asyncio.