gh-135801: Fix inaccurate module info for SyntaxWarnings during AST parsing#135829
gh-135801: Fix inaccurate module info for SyntaxWarnings during AST parsing#135829heliang666s wants to merge 10 commits intopython:mainfrom
Conversation
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
…dule names from filenames rather than the call stack, and streamlines warning emission.
|
@iritkatriel please review again,thanks~ |
|
Any update here? CC @hugovk I believe this would address some / most of the concerns raised on the forum post for PEP 765. It might make sense for 3.14. |
|
FWIW this seems like something that could make sense as a later bugfix in a patch release. Deciding that mostly requires understanding if there are meaningful load bearing behavior changes that code might be relying upon in this PRs warnings and errors changes. |
serhiy-storchaka
left a comment
There was a problem hiding this comment.
The normalize_module() change does not match the Python implementation and the documented behavior. Is it necessary to include it in this PR?
|
Thank you for your PR, @heliang666s, but this was resolved in other way. |
This commit addresses the inaccurate module information provided for SyntaxWarnings during AST parsing, specifically reported in issue #135801.
Previously,
_PyErr_EmitSyntaxWarning(used by the compiler) relied on_PyErr_WarnExplicitObjectWithContextto infer the module name from the call stack. During compilation, this often resulted in misleading module names likesysorimportlib._bootstrap, making it difficult to filter warnings effectively (e.g., using-W error::SyntaxWarning:test).To resolve this, a new internal function
_PyErr_EmitSyntaxWarningFromCompilerwas introduced inPython/errors.c. This function explicitly callsPyErr_WarnExplicitObjectwith aNULLmodule argument, forcing the warning system to derive the module name from the filename provided by the compiler.The
normalize_modulefunction inPython/_warnings.cwas also refined. Instead of simple string manipulation or problematic pure C path parsing, it now leverages Python'sos.pathmodule (via Python C API calls likebasename,splitext, anddirname). This ensures robust and accurate extraction of module names from arbitrary file paths, including correct handling of__init__.pyfiles, thereby providing correct module information for compiler-generatedSyntaxWarningmessages.This approach ensures cross-platform compatibility and reliability by utilizing Python's battle-tested path handling capabilities, directly addressing the core issue reported.