-
-
Notifications
You must be signed in to change notification settings - Fork 30.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gh-93453: No longer create an event loop in get_event_loop() #98440
Conversation
asyncio.get_event_loop() now always return either running event loop or the result of get_event_loop_policy().get_event_loop() call. The latter should now raise an RuntimeError if no current event loop was set instead of creating and setting a new event loop. It affects also a number of asyncio functions and constructors which call get_event_loop() implicitly: ensure_future(), shield(), gather(), etc. DeprecationWarning is no longer emitted if there is no running event loop but the current event loop was set.
👍🏼 to this approach. It would allow us to use the following pattern in
Similarly, in motor (an |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doc/library/asyncio-eventloop.rst
Outdated
.. deprecated:: 3.10 | ||
Deprecation warning is emitted if there is no running event loop. | ||
In future Python releases, this function will be an alias of | ||
:func:`get_running_loop`. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should add a note telling user that in 3.10 and 3.11 (at least up to a certain patch level) this situation would emit a warning.
@serhiy-storchaka Do you want to undraft this? Then we can do a final review and merge it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great -- you can merge now! I won't insist on waiting for Yury.
I do not know the original purpose of the deprecation, so I am not sure that it is the right way. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but please add a what's new entry for this.
Ah, yes, it was a reason why this PR was a draft. Thank you for a reminder. |
Users were getting confused by the meaning of 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 The PR implements that, AFAICT. |
Thank you. I know about problems with creating a new loop in |
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still LGTM. But yeah, let's wait until the 3.11/3.10 PRs have landed.
asyncio.get_event_loop() now always return either running event loop or the result of get_event_loop_policy().get_event_loop() call. The latter should now raise an RuntimeError if no current event loop was set instead of creating and setting a new event loop.
It affects also a number of asyncio functions and constructors which call get_event_loop() implicitly: ensure_future(), shield(), gather(), etc.
DeprecationWarning is no longer emitted if there is no running event loop but the current event loop was set.