| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
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 skip news label instead. |
Sorry, something went wrong.
|
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 skip news label instead. |
Sorry, something went wrong.
Sorry, something went wrong.
…dule names from filenames rather than the call stack, and streamlines warning emission.
|
@iritkatriel please review again,thanks~ |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
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?
Sorry, something went wrong.
|
Thank you for your PR, @heliang666s, but this was resolved in other way. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
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_WarnExplicitObjectWithContext to infer the module name from the call stack. During compilation, this often resulted in misleading module names like sys or importlib._bootstrap, making it difficult to filter warnings effectively (e.g., using -W error::SyntaxWarning:test).
To resolve this, a new internal function _PyErr_EmitSyntaxWarningFromCompiler was introduced in Python/errors.c. This function explicitly calls PyErr_WarnExplicitObject with a NULL module argument, forcing the warning system to derive the module name from the filename provided by the compiler.
The normalize_module function in Python/_warnings.c was also refined. Instead of simple string manipulation or problematic pure C path parsing, it now leverages Python's os.path module (via Python C API calls like basename, splitext, and dirname). This ensures robust and accurate extraction of module names from arbitrary file paths, including correct handling of __init__.py files, thereby providing correct module information for compiler-generated SyntaxWarning messages.
This approach ensures cross-platform compatibility and reliability by utilizing Python's battle-tested path handling capabilities, directly addressing the core issue reported.