Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 33.9k
gh-103186: Suppress and assert expected RuntimeWarnings#103244
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-103186: Suppress and assert expected RuntimeWarnings #103244
Uh oh!
There was an error while loading. Please reload this page.
Conversation
TabLand commented Apr 4, 2023 • edited by bedevere-bot
Loading Uh oh!
There was an error while loading. Please reload this page.
edited by bedevere-bot
Uh oh!
There was an error while loading. Please reload this page.
Caused as a result of frame manipulation where locals are never assigned / initialised
bedevere-bot commented Apr 4, 2023
Most changes to Python require a NEWS entry. Please add it using the blurb_it web app or the blurb command-line tool. |
TabLand commented Apr 4, 2023 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
It doesn't look like it's possible to assert both a warning and an error in tandem. #First AttemptifwarningisnotNoneanderrorisnotNone: withself.assertWarnsRegex(*warning), self.assertRaisesRegex(*error): func(output) #Second AttemptifwarningisnotNoneanderrorisnotNone: withself.assertWarnsRegex(*warning): withself.assertRaisesRegex(*error): func(output)Regardless of the order of the asserts, only the exception is caught / test failed on regex mismatch - and the warning does not bubble up on regex mismatch (test passes whether a warning is raised or not). I'll try and play around on that avenue further, i.e whether it's possible to catch multiple warnings / errors in succession (I'm assuming it's not) and submit an improvement to the docs with what I learn. The current patch would run an output comparison without running the jump tests if both warning and error arguments are supplied in any new tests (not the case for any existing tests). Updating PR shortly... |
bedevere-bot commented Apr 4, 2023
Most changes to Python require a NEWS entry. Please add it using the blurb_it web app or the blurb command-line tool. |
bedevere-bot commented Apr 4, 2023
Most changes to Python require a NEWS entry. Please add it using the blurb_it web app or the blurb command-line tool. |
terryjreedy left a comment • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
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.
On Windows, fresh build (July 10), I get the same runtime warnings as without the patch.
f:\dev\3x>python -m test.test_sys_settrace Running Debug|x64 interpreter... ...f:\dev\3x\Lib\test\test_sys_settrace.py:1895: RuntimeWarning: assigning None to 1 unbound local frame.f_lineno = self.firstLine + self.jumpTo ..f:\dev\3x\Lib\test\test_sys_settrace.py:1895: RuntimeWarning: assigning None to 1 unbound local frame.f_lineno = self.firstLine + self.jumpTo ................................................................................................. f:\dev\3x\Lib\test\test_sys_settrace.py:1818: RuntimeWarning: coroutine method 'aclose' of 'asynciter' was never awaited gc.collect() RuntimeWarning: Enable tracemalloc to get the object allocation traceback ...................................................<traceback object at 0x0000026A38D75EF0> .......................................................................<traceback object at 0x0000026A35F7ABC0> ..................................................................<traceback object at 0x0000026A35F7C690> ...................................................................<traceback object at 0x0000026A38D77F70> ..................................................................<traceback object at 0x0000026A35F7B1B0> ................ ---------------------------------------------------------------------- Ran 439 tests in 6.802s bedevere-bot commented Jul 10, 2023
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 |
TabLand commented Aug 22, 2023 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
I have made the requested changes; please review again. I'm also getting the additional Will check if this issue persists in the main branch and attempt to patch separately |
bedevere-bot commented Aug 22, 2023
Thanks for making the requested changes! @terryjreedy: please review the changes made to this pull request. |
TabLand commented Aug 22, 2023 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
It does not, no further action required |
terryjreedy commented Aug 22, 2023
The 2 'Assigning None' messages, the target of this PR, are gone on a fresh build with this patch added. Good. I am still getting the 3rd warning I and you mentioned above, and the I still need to review the actual code changes and understand them before I could merge. At first glance, it seems that there are more changes than are needed to eliminate the two warnings. Did you add changes for other reasons? |
TabLand commented Aug 22, 2023
Whilst authoring the original change, I noticed that only the initial 2x warnings of the same type / message are printed to console and subsequent warnings are suppressed. This is mentioned in the warnings documentation: https://docs.python.org/3/library/warnings.html |
serhiy-storchaka commented Sep 2, 2023
Do you have an example? |
TabLand commented Sep 3, 2023 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
We don't currently have a test case that requires both a warning and error to be asserted in tandem, I recall I encountered some issues with basic testing where I attempted to assert both in a single test case. Upon further investigation, it is actually possible to assert both errors and warnings in tandem. On my previous attempts, the execution flow may have been interrupted - this doesn't happen when I raise both explicitly: As such, I'll shortly update this PR once more |
Uh oh!
There was an error while loading. Please reload this page.
TabLand commented Sep 6, 2023
@serhiy-storchaka - I've updated this PR code to use contextlib. I've also added an assortment of tandem tests - this helped in identifying that the order of asserting an error's presence, followed by a warning's presence is important in |
serhiy-storchaka left a comment
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.
Thank you for your contribution @TabLand .
I removed new tests because they are not relevant here. The purpose of JumpTestCase is to test setting the frame's f_lineno attribute. All other was simply a tool for testing. New tests only tested this tool, exceptions and warnings were raised not by the f_lineno setter.
bedevere-bot commented Sep 7, 2023
There's a new commit after the PR has been approved. @terryjreedy, @serhiy-storchaka: please review the changes made to this pull request. |
miss-islington commented Sep 7, 2023
Thanks @TabLand for the PR, and @serhiy-storchaka for merging it 🌮🎉.. I'm working now to backport this PR to: 3.12. |
…_sys_settrace (pythonGH-103244) Caused as a result of frame manipulation where locals are never assigned / initialised. (cherry picked from commit 3e53ac9) Co-authored-by: Ijtaba Hussain <ijtabahussain@live.com>
bedevere-bot commented Sep 7, 2023
GH-109066 is a backport of this pull request to the 3.12 branch. |
bedevere-bot commented Sep 7, 2023
|
…t_sys_settrace (GH-103244) (#109066) gh-103186: Suppress and assert expected RuntimeWarnings in test_sys_settrace (GH-103244) Caused as a result of frame manipulation where locals are never assigned / initialised. (cherry picked from commit 3e53ac9) Co-authored-by: Ijtaba Hussain <ijtabahussain@live.com>
These warnings are caused due to locals not being assigned, the initialisation lines are skipped in the jump tests:
A similar assertion is present in test_peepholer.py, which was added in the same commit as the unbound locals check in Objects/frameobject.c
c7065ce#diff-bcf92ed219340e9e0c52401909828c2e9a821541660073e24d64dd996beaf842
Hello @brandtbucher - I can see you authored the unbound locals change, any feedback is appreciated