which, at least up to now, does one of 2 different things:
If there is no current event loop, it asks the current event loop policy to create one and makes it the current event loop
If there is a running event loop, it returns that.
But note that, as of Python 3.10, assuming the first behaviour is deprecated. In future, this function will become a synonym for asyncio.get_running_loop(), which only has the second behaviour.
In fact, the whole idea of referring to a “current” event loop (as opposed to a “currently-running” event loop) is best avoided for the most part, and you will note that asyncio has been adding alternative functions you can use to comply with this. For example, asyncio.run() instead of loop.run_until_complete().
However, these alternative functions are only available as of Python 3.7 or later. So there will need to be some workarounds if you want to maintain compatibility with both pre-3.7 and the future.
Many of us have grown accustomed to writing
which, at least up to now, does one of 2 different things:
But note that, as of Python 3.10, assuming the first behaviour is deprecated. In future, this function will become a synonym for
asyncio.get_running_loop()
, which only has the second behaviour.In fact, the whole idea of referring to a “current” event loop (as opposed to a “currently-running” event loop) is best avoided for the most part, and you will note that
asyncio
has been adding alternative functions you can use to comply with this. For example,asyncio.run()
instead of loop.run_until_complete()
.However, these alternative functions are only available as of Python 3.7 or later. So there will need to be some workarounds if you want to maintain compatibility with both pre-3.7 and the future.