FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

gh-135801: Fix inaccurate module info for SyntaxWarnings during AST parsing by heliang666s · Pull Request #135829 · python/cpython · GitHub

Repository navigation

gh-135801: Fix inaccurate module info for SyntaxWarnings during AST parsing - #135829

Closed
heliang666s wants to merge 10 commits into
python:mainfrom
heliang666s:main
Closed

heliang666s wants to merge 10 commits into
python:mainfrom
heliang666s:main

Conversation

heliang666s commented Jun 23, 2025 •
edited by bedevere-app Bot
Loading

Copy link
Copy Markdown
Contributor

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.

bedevere-app Bot commented Jun 23, 2025

Copy link
Copy Markdown

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.

bedevere-app Bot commented Jun 23, 2025

Copy link
Copy Markdown

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.

python-cla-bot Bot commented Jun 23, 2025 •
edited
Loading

Copy link
Copy Markdown

All commit authors signed the Contributor License Agreement.

Comment thread Python/errors.c Outdated
heliang666s and others added 2 commits June 30, 2025 01:53
…dule names from filenames rather than the call stack, and streamlines warning emission.

heliang666s commented Jun 30, 2025 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

@iritkatriel please review again,thanks~

cdce8p commented Aug 30, 2025

Copy link
Copy Markdown
Contributor

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.
https://discuss.python.org/t/pep-765-disallow-return-break-continue-that-exit-a-finally-block/71348/146

gpshead commented Oct 2, 2025

Copy link
Copy Markdown
Member

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

The normalize_module() change does not match the Python implementation and the documented behavior. Is it necessary to include it in this PR?

Copy link
Copy Markdown
Member

Thank you for your PR, @heliang666s, but this was resolved in other way.

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants


Back | FazBrowse Home | New Git URL