Skip to content

Do not display import-related errors after module-level always false assert #19347

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

sterliakov
Copy link
Collaborator

Fixes #19346

@sterliakov sterliakov marked this pull request as ready for review June 26, 2025 23:04
@sterliakov sterliakov marked this pull request as draft June 26, 2025 23:33
@sterliakov sterliakov marked this pull request as ready for review June 27, 2025 00:22

This comment has been minimized.

@A5rocks
Copy link
Collaborator

A5rocks commented Jun 29, 2025

One reason I'm surprised about this is that my impression was that after a module-level assert that is unreachable, mypy removes all nodes. Am I misremembering? Or is this an earlier pass?

@sterliakov
Copy link
Collaborator Author

@A5rocks Great question. Imports are collected during parsing, and "definitely unreachable" truncation step follows (SemanticAnalyzerPreAnalysis). It does not modify MypyFile.imports collected at the previous step, so we still treat such modules as dependencies even if the corresponding import statement no longer exists, and "missing module" errors are produced by build manager when any dependency can't be resolved. Those imports aren't marked unreachable either. That probably should be fixed instead, thanks! That will be a better approach.

This comment has been minimized.

Copy link
Collaborator

@A5rocks A5rocks left a comment

Choose a reason for hiding this comment

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

This makes sense to me!

This comment has been minimized.

This comment has been minimized.

Copy link
Contributor

github-actions bot commented Jul 7, 2025

Diff from mypy_primer, showing the effect of this PR on open source code:

PyWinCtl (https://github.com/Kalmat/PyWinCtl)
- src/pywinctl/_pywinctl_win.py:28: error: Cannot find implementation or library stub for module named "pywinbox"  [import-not-found]
- src/pywinctl/_pywinctl_macos.py:25: error: Cannot find implementation or library stub for module named "pywinbox"  [import-not-found]

@petamasS3D
Copy link

@A5rocks , @JukkaL
Last meaningful change is 2 weeks old on this PR - how can this be unblocked?

@sterliakov
Copy link
Collaborator Author

@petamasS3D just wait - I usually follow up on my PRs monthly if they lack attention. Things just aren't quickly merged here except for trivial fixes/emergencies, and this one certainly isn't a trivial fix (and is a bit hacky), so it's normal to wait a while and gather feedback from other maintainers. If this issue is blocking you, you can safely add an ignore comment - typechecker false positive is one of perfectly legitimate reasons to use them.

@petamasS3D
Copy link

@sterliakov: thanks for the insight! I saw that there are a LOT of newer PRs already merged, and was afraid this one somehow got lost. It's not blocking me at the moment (I've worked around the issue using an if around the imports, and asserting afterwards), just hoped for a quick resolution after you immediately jumped on my bug report. (Thank you for that!) I'll wait patiently until the process completes. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

mypy tries to follow imports in files with top-level sys.platform asserts on non-matching platforms
3 participants