-
Notifications
You must be signed in to change notification settings - Fork 1.6k
[red-knot] Trust all symbols in stub files #17588
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
Conversation
|
|
Oh, I suppose a lot of class-level assignments in typeshed are in the context of enum classes (e.g. https://github.com/python/typeshed/blob/ae57d69c9354147bcf7086d6db47af8f8c82bf7b/stdlib/re.pyi#L201-L221 ), and we infer all attributes on enums as |
|
I found one example that we do infer differently on this branch! I'm sure it's widely used: from pdb import Pdb
reveal_type(Pdb.do_b) # Previously: Unknown | def do_break(self, arg: str, temporary: bool = EllipsisType) -> bool | None
# Now: def do_break(…) -> … |
|
This does still feel more consistent to me, so I do support it still! |
6f727ff to
c00dad7
Compare
carljm
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this makes sense as well. Sorry I didn't get through my notifications fast enough to comment on the previous PR sooner!
The core "gradual guarantee" idea that we should not emit false positives on working untyped code, when the user hasn't declared their intentions through type annotations, just doesn't apply to stub files in the same way, since they are inherently somebody explicitly providing type information.
Summary
Follow-up on the discussion here. Generally trust undeclared symbols in stubs, not just at the module level.
Test Plan
New Markdown test.