👍🏼 to this approach. It would allow us to use the following pattern in jupyter_client to be able to create a ready future in a constructor when there is no event loop running:

def __init__(self):
      try:
            self._ready = asyncio.Future()
      except RuntimeError:
            asyncio.set_event_loop(get_event_loop_policy().get_event_loop())
            self._ready = asyncio.Future()

Similarly, in motor (an asyncio version of pymongo), we currently delay the creation of the event loop used by the async client, and could do so in the constructor as well.

@serhiy-storchaka Do you want to undraft this? Then we can do a final review and merge it.

I do not know the original purpose of the deprecation, so I am not sure that it is the right way.

Ah, yes, it was a reason why this PR was a draft. Thank you for a reminder.

I do not know the original purpose of the deprecation, so I am not sure that it is the right way.

Users were getting confused by the meaning of get_event_loop(), which sometimes created a new loop and sometimes didn't. They also misunderstood the meaning of set_event_loop() and would create and set a new loop when a loop already existed. We were so frustrated with this that we decided to change the semantics of get_event_loop() to only return the currently-running loop (i.e., get_running_loop()), but since that was a semantic change we introduced a deprecation first.

Then we heard from users who did understand the mechanism and were using it to solve an issue they couldn't easily solve in any other way, and we changed our mind. The current idea is that get_event_loop() should never create a new loop (it's better to have control over that and use new_event_loop() or better asyncio.run()) but it should still be possible to set a loop in the policy object's thread locals, and get that.

The PR implements that, AFAICT.

Thank you. I know about problems with creating a new loop in get_event_loop(). Initially Andrew was going to deprecate get_event_loop() at all, but I proposed to keep in case if it returns an existing loop, so the existing code written before introduction of get_running_loop() will not need changes. But a corner case, when get_event_loop() returns an existing loop which is not a running loop was not clear to me.

I am planning to merge this PR only after creating a PR for 3.11 to undeprecate what was incorrectly deprecated.

See #99949.

NOTE: this PR assumes the fix backports will be landed in time for 3.10.9 and 3.11.1. This is currently in question (see GH-99949) so please monitor the 3.10 and 3.11 PRs before landing this one.