Skip to content
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

[red-knot] Add failing tests for * imports #16873

Merged
merged 3 commits into from
Mar 21, 2025
Merged

Conversation

AlexWaygood
Copy link
Member

Summary

This PR adds a suite of tests for wildcard (*) imports. The tests nearly all fail for now, and those that don't, ahem, pass for the wrong reasons...

I've tried to add TODO comments in all instances for places where we are currently inferring the incorrect thing, incorrectly emitting a diagnostic, or emitting a diagnostic with a bad error message.

Test Plan

cargo test -p red_knot_python_semantic

@AlexWaygood AlexWaygood added the red-knot Multi-file analysis & type inference label Mar 20, 2025
`c.py`:

```py
from b import *
Copy link
Member Author

Choose a reason for hiding this comment

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

the reason why we do not emit an error here is somewhat horrifying... we're currently inserting a global-scope symbol with the name "*" in the symbol table for b.py

@AlexWaygood AlexWaygood force-pushed the alex/star-imports-tests branch from 697ac20 to 66aff0a Compare March 20, 2025 16:29
Copy link
Contributor

github-actions bot commented Mar 20, 2025

mypy_primer results

No ecosystem changes detected ✅

Copy link
Contributor

@carljm carljm left a comment

Choose a reason for hiding this comment

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

Looks great!

reveal_type(X) # revealed: Unknown
```

## Star imports with `__all__`
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this could be done separately from the initial PR, but I'm guessing that's already your plan; having it in the initial set of tests doesn't preclude that, this test can just keep its TODOs longer.

Copy link
Member Author

Choose a reason for hiding this comment

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

yup, exactly

Comment on lines +341 to +344
1. Emit a diagnostic at the invalid definition of `__all__` (which will not fail at runtime)?
1. Emit a diagnostic at the star-import from the module with the invalid `__all__` (which _will_
fail at runtime)?
1. Emit a diagnostic on both?
Copy link
Contributor

Choose a reason for hiding this comment

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

I would go for the first. If code is definitely wrong, even if it won't actually error at runtime until "used", I think it's generally better if we issue the error closer to the source, and not further from the source (which might be code with a different author who can't do anything about the problem.)

Copy link
Member Author

@AlexWaygood AlexWaygood Mar 21, 2025

Choose a reason for hiding this comment

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

I'm sort of inclined to go for the third: emit diagnostics at both locations?

  • Having an invalid __all__ and having an import statement that we can say for sure will fail both seem like distinct errors that I'd want to know about if writing a Python module (even if they both have the same root cause)
  • If the module you're importing from is third-party and has an invalid __all__ but we only emit an error where __all__ is defined, the user won't get any warning that their * import from the third-party module will fail, since we don't display diagnostics relating to type errors in third-party code. This isn't that far-fetched: we've had several situations at typeshed where the library we're stubbing has an invalid __all__ and this was never detected by the library's tests (though it was caught by typeshed's tests!)

@AlexWaygood
Copy link
Member Author

Added some more tests in 7cf8eab ... I don't think they're contentious, but happy to address any comments in a followup! Merging for now.

@AlexWaygood AlexWaygood enabled auto-merge (squash) March 21, 2025 14:16
@AlexWaygood AlexWaygood merged commit 14eb4ca into main Mar 21, 2025
22 checks passed
@AlexWaygood AlexWaygood deleted the alex/star-imports-tests branch March 21, 2025 14:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
red-knot Multi-file analysis & type inference
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants