gh-94597: deprecate asyncio.set_event_loop_policy by graingert · Pull Request #110728 · python/cpython (original) (raw)

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 andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

Contributor

@graingert graingert commented

Oct 11, 2023

•

edited by bedevere-appbot

graingert changed the title~~deprecate asyncio.set_event_loop_policy~~ gh-94597: deprecate asyncio.set_event_loop_policy

Oct 11, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No objection to the unittest or AsyncMock changes!

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a few nits, basically LG. That tearDownModule() pattern is annoying! :-)

I assume that deprecating get_event_loop_policy() will follow? Are there other APIs? I'm guessing we also want to avoid instantiating or subclassing the standard event loop policy classes (I expect this will turn up some significant uses of them).

Before we merge this we may need to bring this up on discuss.python.org (in the asyncio category) to see if there are significant objections to the proposed deprecation schedule.

…o8Q4.rst

Co-authored-by: Guido van Rossum gvanrossum@gmail.com

Just a few nits, basically LG. That tearDownModule() pattern is annoying! :-)

I think we can start getting rid of those tearDownModules using #110774

I assume that deprecating get_event_loop_policy() will follow? Are there other APIs? I'm guessing we also want to avoid instantiating or subclassing the standard event loop policy classes (I expect this will turn up some significant uses of them).

Yep currently that's a bit more complicated because get/set_event_loop calls get_event_loop_policy and afaik we don't want to make get_event_loop an alias of get_running_loop anymore

Co-authored-by: Hugo van Kemenade hugovk@users.noreply.github.com

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I'm happy with this. Let's wait a bit if anyone brings up substantial objections in the Discourse thread.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please also add a notice under asyncio changes, most users like myself won't look under 3.15 removals for this change. Thanks

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

And if you don't make the requested changes, you will be poked with soft cushions!