Repository navigation
Syntax warnings can be swallowed in import #139640
Description
Activity
- added 4 commits that reference this issue
on Oct 6, 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).And #139755 is the third alternative that simply restores the double PEP 765 warnings.
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:
- if AST optimisation is skipped when parsing, the warning doesn't get emitted
- if the AST is optimised during parsing, and then optimised again during code generation, the warning gets emitted twice
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)
Reacted by Marc Mueller1 remaining item
- added 6 commits that reference this issue
on 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.
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.
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?
Yes.
Reacted by Alyssa Coghlan
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 isimportlib._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/continueinfinally) -- they are only emitted during compiling.Linked PRs