Ben Darnell <ben.darn...@gmail.com> added the comment:

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

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue39529>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to