This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Ben.Darnell
Recipients Ben.Darnell, aeros, asvetlov, minrk, serhiy.storchaka, xtreak, yselivanov
Date 2021-12-03.19:52:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1638561165.58.0.836768924173.issue39529@roundup.psfhosted.org>
In-reply-to
Content
> In IPython, I think you could use new_event_loop() for getting a new loop instance.
> Then, save the loop reference somewhere as a direct attribute, threading.local or ContextVar.
> Calling loop.run_until_complete() looks pretty normal in your situation.

That works if you're a leaf in the dependency tree, but what about a library like Tornado (which IPython depends on)? If intermediate libraries (say Tornado and Twisted) introduce their own thread-local loops for backwards compatibility of their existing interfaces, the ecosystem gets fragmented again. Having the thread-local live in asyncio is useful for seamless interoperability across frameworks. 

> asyncio.run() is entirely self-reliant in that it creates all needed resources at the start and closes them in finalization, rather than depending on existing resources. I believe this to be significantly safer and better guaranteed to function as intended, although perhaps at some cost to convenience in cases like your own where there only needs to be one event loop.

Whether or not this is more likely to function as intended depends on assumptions about user expectations. In Tornado (and other async systems I have used in the past), it is the norm to set up handlers on an event loop while it is not running and then start it afterwards. The behavior of asyncio.run is surprising to me. Maybe I'm weird, but regardless of which behavior is surprising to the fewest people, my point is that this change is very disruptive to Tornado and most applications using it, contrary to the claim that the maintenance burden should be pretty low.

I realize it may be too late to change course, but my preference would have been to resolve the conflict between get_event_loop and asyncio.run by making asyncio.run essentially an alias for asyncio.get_event_loop().run_until_complete. This would relax the isolation of asyncio.run, but that doesn't seem very important to me. The comparable idioms in Tornado (using the IOLoop.run_sync method) all work this way and I've never seen any confusion related to this or a situation in which creating a brand-new event loop in run_sync would be desirable.
History
Date User Action Args
2021-12-03 19:52:45Ben.Darnellsetrecipients: + Ben.Darnell, asvetlov, serhiy.storchaka, yselivanov, minrk, xtreak, aeros
2021-12-03 19:52:45Ben.Darnellsetmessageid: <1638561165.58.0.836768924173.issue39529@roundup.psfhosted.org>
2021-12-03 19:52:45Ben.Darnelllinkissue39529 messages
2021-12-03 19:52:45Ben.Darnellcreate