-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Wrong overload resolution with Any union item in argument #5249
Comments
I think we should switch to a new union math algorithm, I have some ideas how to make it fast enough to replace the current one (that is apparently to dangerous). I will give it a try now. |
Another real-world example where things go wrong: from typing import Union, Any, List
i: Union[int, Any]
a: List[int]
reveal_type(a[i]) # Union[int, List[int]] |
I think that one is actually correct: if |
from typing import Union, Any
class A:
x: str
class B:
x: int
a: Union[A, Any]
reveal_type(a.x) # Union[str, Any] We don't infer |
The PR I am working on will produce (after some tweaks that I didn't push yet) from typing import Union, Any, List
i: Union[int, Any]
a: List[int]
reveal_type(a[i]) # Union[int, Any] @JukkaL does this make sense to you? |
(Also I think |
Yes, I think that |
Fixes #5243 Fixes #5249 Some comments: * I went ahead with a slow but very simple recursive algorithm that treats all various complex cases correctly. On one hand it can be exponential, but on the other hand, the complexity will be bad _only_ if user abuses lots of unions * I use a hack caused by the fact that currently most function inference functions pass argument _expressions_ instead of types, I left a TODO to use a more unified approach similar to multiassign_from_union * It may look like there are many changes in tests, but actually there are not, the differences are because: - Error messages now show the _first potentially matching_ overload (which is OK I think) - Order of items in many unions turned to the opposite, apparently union `__repr__` is unstable.
This fragment derived from production code causes a false positive:
Here's a self-contained repro:
I'd expect the inferred type for
x.f(y)
to beUnion[D, Any]
(or maybeD
, though it's slightly less correct arguably).The text was updated successfully, but these errors were encountered: