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

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