-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
gh-111085 Fix logic order causing nicer error to never be raised in asyncio.Timeout #110910
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
Conversation
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.
Thanks for fixing this! However, it does need a NEWS entry since exception type change is user visible behaviour
@hauntsaninja does this also need an issue then? |
Yeah, it's not possible to add a news entry without linking the news entry to a GitHub issue. (Or, shouldn't be possible, anyway, since the news entry is meant to be linked to an issue :p ) |
…0-19-11-40-38.gh-issue-111085.hBPpQr.rst
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. Should it be backported to 3.12?
Turns out the bug exists on 3.11 as well |
I think this probably should not be backported. This effectively just changes a bad error message to a good one and has a chance of breaking code, so doesn't feel like good cost benefit. Thanks again, I see Serhiy self requested review, so will wait for that before merging. |
asyncio.TaskGroup and asyncio.Timeout classes now raise proper RuntimeError if they are improperly used. * When they are used without entering the context manager. * When they are used after finishing. * When the context manager is entered more than once (simultaneously or sequentially). * If there is no current task when entering the context manager. They are now left in consistent state after raising an exception, so following operations can be correctly performed (if they are allowed).
asyncio.TaskGroup and asyncio.Timeout classes now raise proper RuntimeError if they are improperly used. * When they are used without entering the context manager. * When they are used after finishing. * When the context manager is entered more than once (simultaneously or sequentially). * If there is no current task when entering the context manager. They are now left in consistent state after raising an exception, so following operations can be correctly performed (if they are allowed). Co-authored-by: James Hilton-Balfe <[email protected]>
asyncio.TaskGroup and asyncio.Timeout classes now raise proper RuntimeError if they are improperly used. * When they are used without entering the context manager. * When they are used after finishing. * When the context manager is entered more than once (simultaneously or sequentially). * If there is no current task when entering the context manager. They are now left in consistent state after raising an exception, so following operations can be correctly performed (if they are allowed). Co-authored-by: James Hilton-Balfe <[email protected]>
Closing in favour of #111111 |
While this change fixes an AttributeError in In any case, thank you for your contribution. I included your changes in the other PR and added you as a co-author. |
I don't think this needs a news entry or an issue