-
Notifications
You must be signed in to change notification settings - Fork 1.6k
[ty] Use specialized parameter type for overload filter #19964
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
Diagnostic diff on typing conformance testsNo changes detected when running ty on typing conformance tests ✅ |
|
628363b to
5ebe3e6
Compare
This reverts commit 5ebe3e6.
|
| Lint rule | Added | Removed | Changed |
|---|---|---|---|
invalid-argument-type |
14 | 0 | 0 |
invalid-assignment |
9 | 0 | 0 |
no-matching-overload |
7 | 2 | 0 |
possibly-unbound-attribute |
0 | 0 | 4 |
call-non-callable |
3 | 0 | 0 |
unresolved-attribute |
2 | 0 | 0 |
invalid-return-type |
1 | 0 | 0 |
missing-argument |
1 | 0 | 0 |
possibly-unbound-implicit-call |
0 | 0 | 1 |
redundant-cast |
1 | 0 | 0 |
| Total | 38 | 2 | 5 |
This is interesting, it seems that a decorator that returns a callable on a method is removing the fact that the original function is an instance method: def __rmatmul__(self, other: MatrixBase) -> MatrixBase:
self, other, T = _unify_with_other(self, other)
if T != "is_matrix":
return NotImplemented
# This is the revealed type with the `call_highest_priority` decorator
# ty: Revealed type: `Unknown | ((Unknown, Unknown, /) -> Unknown)` [revealed-type]
# Pyright: Type of "self.__rmul__" is "(MatrixBase | Expr | complex) -> MatrixBase"
return reveal_type(self.__rmul__)(other)
# And, this is without the decorator
# ty: Revealed type: `Unknown | (bound method MatrixBase.__rmul__(other: MatrixBase | Unknown) -> MatrixBase)` [revealed-type]
@call_highest_priority('__mul__')
def __rmul__(self, other: MatrixBase | SExpr) -> MatrixBase:
return self.rmultiply(other)This wasn't an easy before this PR because the call to an overloaded function |
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.
Nice!
Summary
Closes: astral-sh/ty#669
(This turned out to be simpler that I thought :))
Test Plan
Update existing test cases.
Ecosystem report
Most of them are basically because ty has now started inferring more precise types for the return type to an overloaded call and a lot of the types are defined using type aliases, here's some examples:
Details
This is accurate now that we infer the type as
Literal[42]instead ofUnknown(Pyright infers it asint)Same as above where ty is now inferring a more precise type like
Unknown | ndarray[tuple[int, int], <class 'float'>]instead of justUnknownas beforeThis requires support for type aliases to match the correct overload.
Same as above, this requires support for type aliases to match the correct overload.
This is correct.
Most of them are correct except for the last two diagnostics which I'm not sure
what's happening, it's trying to index into an
np.ndarraytype (which isinferred correctly) but I think it might be picking up an incorrect overload
for the
__getitem__method.Scipy's diagnostics also requires support for type alises to pick the correct overload.