Discussion or tracking tickets for move to asyncio.get_running_loop()

Hi.

Comment from @asvetlov on https://github.com/python/cpython/pull/15889#discussion_r322860377, which is ref the deprecation of the explicit loop argument in asyncio’s public API:

In Python 3.9 I have a plan to add another deprecation warning if not self._loop.is_running() for queues and locks and eventually replace get_event_loop() with get_running_loop() as a final fix.

I’m interested in this, with a possible eye to getting my feet wet. Is there a discussion outlining the intended direction, or tracking tickets covering the work to be done, or…? (I couldn’t find anything looking, but I may just not know the place.) (Did search the issue tracker without luck…)

Thanks!

I don’t recall where I wrote this but the current design can produce a weird result.
Consider the following:

import asyncio

lock = asyncio.Lock()

async def main():
    ...

asyncio.run(main())

This example is very dangerous and potentially leads to a hang because lock and main() use different loop instances.

Hi Andrew, Thanks for the reply…

Yes, that’s a good example. From resolving the previous issue with tracking the event loop across threads, we’re seeing reports of users hitting almost exactly this issue, whereby a asyncio.Lock() is using the default rather than the running loop. (The tl;dr seems to be that we need to call set_event_loop() to set the correct loop.)

The discussion pointed to this issue aiohttp#3331 — where you’re using get_event_loop inside the get_running_loop() helper. Is the plan to drop that helper once Python 3.7 is the minimum supported version?

Looking at the source of asyncio.Lock and friends, it looks as if a deferred call to get_running_loop() when self._loop is first accessed would allow this problem to be avoided. BUT, and hence my query here, I’m not at all sure if that’s the right/considered approach, so I was looking for any design/roadmap docs that point the way forward.

The thought of how the deprecation path looks is a bit :thinking: — It’s only from discussion here and then digging that I’m gaining clarity, so I thought helping with the docs might be good.

I thought I could get setup and see if I could potter away a bit there. It’s small enough in scope for me to get started without feeling too out of depth too quickly — but I still feel like I’m missing the top-level perspective.

Thanks!

(Sorry for the lack of proper links: the editor won’t let me post. I guess that’s a trust/spam thing. Update, got promoted.)

With get_event_loop() I can support existing code but raise a warning. After exhausting the deprecation period it can be replaced with strong get_running_loop(), sure.

In aiohttp on the master the situation is a little different: the project runs out the deprecation for this particular warning already; the warning is converted to error. I need to keep get_event_loop() until dropping Python 3.6 support, you are 100% correct.