gh-111085 Fix logic order causing nicer error to never be raised in asyncio.Timeout#110910
gh-111085 Fix logic order causing nicer error to never be raised in asyncio.Timeout#110910Gobot1234 wants to merge 4 commits intopython:mainfrom
Conversation
|
@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
Eclips4
left a comment
There was a problem hiding this comment.
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 <gobot1234yt@gmail.com>
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 <gobot1234yt@gmail.com>
|
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