Repository navigation
Syntax warnings can be swallowed in import #139640
Description
Bug report
As I worked on issue #135801, I realized that the solution to issue #131927 was wrong. _PyErr_WarnExplicitObjectWithContext() takes the module name and the warning registry from the current Python frame. In case of import it is importlib._bootstrap_external.
Wrong module name which makes difficult to filter syntax warnings is an old issue, but the main problem is that syntax warnings for imported modules share the same warning registry. When you import two modules why by accident emit the same syntax warning at the same line number, you will only see one warning by default. It may be argued that swallowing a warning is worse that emitting a warning twice.
The following PR reverts PR #131993 and provides an alternative solution that fixes all double warnings but keeps warnings for repeated compilation. ast.parse() no longer emits warnings that are emitted in the AST optimizer (return/break/continue in finally) -- they are only emitted during compiling.
Linked PRs
- gh-131927: Do not emit PEP 765 warnings in ast.parse() #139642
- gh-131927: Silence PEP 765 warnings in PyREPL #139719
- gh-139640: Fix swallowing syntax warnings in different modules (restore duplicated PEP 765 warnings) #139755
- [3.14] gh-139640: Fix swallowing syntax warnings in different modules (GH-139755) #140117
- [3.13] gh-139640: Fix swallowing syntax warnings in different modules (GH-139755) #140119
- Add mention of other fixed bug in the gh-139640 NEWS entry #140122
Activity
pythongh-139640: Fix swallowing syntax warnings in different modules
pythongh-139640: Fix swallowing syntax warnings in different modules
pythongh-139640: Fix swallowing syntax warnings in different modules
pythongh-139640: Fix swallowing syntax warnings in different modules
serhiy-storchaka commentedon Oct 7, 2025
#139719 is an alternative solution that keeps the PEP 765 warnings in
ast.parse(), but silence them in the REPL. It is based on the original solution proposed by @tomasr8 in #131927 (comment).pythongh-139640: Fix swallowing syntax warnings in different modules
serhiy-storchaka commentedon Oct 8, 2025
And #139755 is the third alternative that simply restores the double PEP 765 warnings.
pythongh-139640: Fix swallowing syntax warnings in different modules
ncoghlan commentedon Oct 8, 2025
Switching to commenting here now that there are multiple related PRs.
The PEP text assumed that it would be feasible to emit the syntax warnings during the actual AST construction pass (the part that doesn't get reexecuted when opcodes are generated from an already parsed AST).
Emitting the warning during the AST optimiser pass doesn't really meet the intent of that part of the PEP:
So if it isn't practical to emit the warning during the initial construction pass, I think it would be reasonable to say that part of the proposal proved harder to implement correctly than expected, flipping the effort vs reward balance, and fall back to just emitting the warning during code generation.
(I've also personally changed my mind on the value of emitting the warning eagerly - a linter parsing that code has its own approach to reporting issues, so the early syntax warning is going to be annoying, not helpful)
1 remaining item
gh-139640: Fix swallowing syntax warnings in different modules (GH-13…
pythongh-139640: Fix swallowing syntax warnings in different modules (p…
[3.13] pythongh-139640: Fix swallowing syntax warnings in different m…
[3.13] pythongh-139640: Fix swallowing syntax warnings in different m…
Add mention of other fixed bug in the pythongh-139640 NEWS entry
[3.13] gh-139640: Fix swallowing syntax warnings in different modules (…
[3.14] gh-139640: Fix swallowing syntax warnings in different modules (…
Add mention of other fixed bug in the gh-139640 NEWS entry (GH-140122)
ncoghlan commentedon Oct 14, 2025
I'm OK with switching to emitting the warnings during code generation due to the unforeseen consequences of trying to emit them earlier.
@iritkatriel Are you OK with that? (I believe I was the main proponent of emitting them early, but I could easily be misremembering that)
I'm not sure if we should file an SC issue or not - Serhiy is fixing a bug, and the fact that it's a design bug rather than purely an implementation issue doesn't change the fact that it's a bug.
serhiy-storchaka commentedon Oct 14, 2025
I have merged the smallest of PRs -- the one which simply restores the duplicate warnings. Two other PRs are now alternative solutions of the re-opened #131927.
I thought that the previous fix also fixed duplicate warnings in the finally block -- but it was not so. So #139755 actually fixed two different warnings. If I knew, I would create two different issues for this.
iritkatriel commentedon Oct 14, 2025
Yes.
pythongh-139640: Fix swallowing syntax warnings in different modules (p…
Add mention of other fixed bug in the pythongh-139640 NEWS entry (pyt…