GeezerVison is showing github.com — Compilation emits multiple warnings in the finally block · Issue #131927 · python/cpython
Compilation emits multiple warnings in the finally block #131927Labels 3.12only security fixesonly security fixes3.13only security fixesonly security fixes3.14bugs and security fixesbugs and security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error DescriptionBug report
This code produces two SyntaxWarnings in the new REPL:
>>> def some():
... try:
... return 1
... finally:
... return 2
...
<python-input-14>:5: SyntaxWarning: 'return' in a 'finally' block
<python-input-14>:5: SyntaxWarning: 'return' in a 'finally' block 
But, in our old REPL it produces just one:
Other SyntaxWarnings also do not show the same behavior in the new REPL. Example:
So, looks like only PEP-765 is affected, only in the new REPL.
CC @ambv @iritkatriel
Linked PRs
Activitytomasr8 commented on Mar 31, 2025 I think the issue is that we compile the source twice, once we compile to an AST and second time from the AST to a code object. The warning comes from the AST optimizer so it is emitted both times:
|
try: |
|
tree = self.compile.compiler( |
|
source, |
|
filename, |
|
"exec", |
|
ast.PyCF_ONLY_AST, |
|
incomplete_input=False, |
|
) |
|
except (SyntaxError, OverflowError, ValueError): |
|
self.showsyntaxerror(filename, source=source) |
|
return False |
|
if tree.body: |
|
*_, last_stmt = tree.body |
|
for stmt in tree.body: |
|
wrapper = ast.Interactive if stmt is last_stmt else ast.Module |
|
the_symbol = symbol if stmt is last_stmt else "exec" |
|
item = wrapper([stmt]) |
|
try: |
|
code = self.compile.compiler(item, filename, the_symbol) |
|
linecache._register_code(code, source, filename) |
A very simple fix for this would be to catch this warning on the second compilation, something like this:
diff --git a/Lib/_pyrepl/console.py b/Lib/_pyrepl/console.py
index 8956fb1242..9d461980be 100644
--- a/Lib/_pyrepl/console.py
+++ b/Lib/_pyrepl/console.py
@@ -204,8 +204,26 @@ def runsource(self, source, filename="<input>", symbol="single"):
wrapper = ast.Interactive if stmt is last_stmt else ast.Module
the_symbol = symbol if stmt is last_stmt else "exec"
item = wrapper([stmt])
+ import warnings
try:
- code = self.compile.compiler(item, filename, the_symbol)
+ with warnings.catch_warnings(record=True) as caught_warnings:
+ # Enable all warnings
+ warnings.simplefilter("always")
+ code = self.compile.compiler(item, filename, the_symbol)
+ for warning in caught_warnings:
+ if issubclass(warning.category, SyntaxWarning) and "in a 'finally' block" in str(warning.message):
+ # Ignore this warning as it would've alread been raised
+ # when compiling the code above
+ pass
+ else:
+ # Re-emit other warnings
+ warnings.warn_explicit(
+ message=warning.message,
+ category=warning.category,
+ filename=warning.filename,
+ lineno=warning.lineno,
+ source=warning.source
+ )
linecache._register_code(code, source, filename)
except SyntaxError as e:
if e.args[0] == "'await' outside function":I can send a PR for this later today unless you were already working on it @sobolevn ? mdboom commented on Mar 31, 2025 iritkatriel commented on Mar 31, 2025 Why does the repl need the ast? sobolevn commented on Mar 31, 2025 No, I don't plan to work on this issue, because I don't know how to solve it :) changed the title [-]PEP765 produces two warnings in the new REPL[/-] [+]PEP 765 produces two warnings in the new REPL[/+] on Mar 31, 2025iritkatriel commented on Mar 31, 2025
Why does the repl need the ast?
Looks like it's walking the AST and then constructing an AST for each statement on its own and executing that. Not sure why.
I don't like the solution proposed above (suppressing the warnings) because I think we will add other syntax warnings to this stage later on (including moving some that are not in the compiler so that they show up in static analysis), and I don't want us to have to special case each one of them. Let's think of something else. Reacted by Mikhail Efimov and sobolevn tomasr8 commented on Mar 31, 2025 Indeed, the solution I proposed is pretty brittle, especially if we're planning to add more warnings in the future. I'll see if I can come up with another solution. iritkatriel commented on Mar 31, 2025 One thing we could do is to define a subclass of SyntaxWarning which is only raised from the ast_opt stage, and then this type can be filtered out.
(note that ast_opt is in the process of being renamed in #131830 (comment), so maybe wait till that's merged). tomasr8 commented on Mar 31, 2025 That sounds like a good option! I'll wait for the other PR to land :) iritkatriel commented on Mar 31, 2025 Actually, adding a new builtin warning type would need a PEP, and this is probably overkill for this problem.
Maybe we can just mark the SyntaxWarning as "coming from ast_opt" in some way that the real can query? tomasr8 commented on Mar 31, 2025 Or a way to turn off warnings coming from ast_opt? Though that also seems like overkill for such a niche use case. serhiy-storchaka commented on Apr 12, 2025 There were at least three different bugs:
- Compiling the
finally block could emit two warnings, because the code in the finally block is compiled twice.
- Repeated
compile() calls emitted repeated warnings.
- New REPL also emits repeated PEP-765 related warnings.
The PR fixed them all. Maybe backport it, as the first two issues are old? Reacted by Irit Katriel and Tomas R. serhiy-storchaka commented on Oct 6, 2025 I realized that this was incorrect solution. See #139640. serhiy-storchaka commented on Oct 14, 2025 #139642 and #139719 are two alternative solutions. The former makes ast.parse() not emitting warnings. The simply silences it in the REPR (the original solution by @tomasr8). It may be incomplete because we may need to silence warnings in other places of the stdlib, not mention a third-party code. ncoghlan commented on Oct 29, 2025 @serhiy-storchaka Based on the discussion in #139640, I posted an approving review on #139642, so I think we can close #139719 in favour of the more straightforward (and comprehensive) solution.
MetadataMetadata3.12only security fixesonly security fixes3.13only security fixesonly security fixes3.14bugs and security fixesbugs and security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error DevelopmentNo branches or pull requestsIssue actions
|
