Overloads not resolved correctly when argument is `Any` and return types use `TypeGuard` or `TypeIs`
@sobolevn is already working on this.
Since Aug 13, 2024.
- Dominant language
- Python
- Stars
- 20.6k
- Forks
- 3.3k
- PR merge metrics
- PR metrics pending
Description
When overload matching is ambiguous due to an Any argument, mypy typically looks at the return types of the potential matches. If the return types differ, it evaluates the return type as Any to preserve the "gradual type guarantee". It apparently doesn't do this when the return types of the potential overload matches use TypeIs. See the example below, where mypy matches the first overload rather than detecting the ambiguity and evaluating Any.
from typing import Any, overload
from typing_extensions import TypeIs
@overload
def func1(x: str) -> TypeIs[str]:
...
@overload
def func1(x: int) -> TypeIs[int]:
...
def func1(x: Any) -> Any:
return True
def func2(val: Any):
if func1(val):
reveal_type(val) # Should be Any
I discovered this problem because pyright has the same issue. I'm guessing that the underlying cause of the bug in mypy is similar. Pyright's logic was treating TypeIs[T] as equivalent to bool in this case, but TypeIs[T] should be treated as a subtype of bool. Also, TypeIs[X] is not equivalent to TypeIs[Y] unless X is equivalent to Y.
This bug affects a recent change in typeshed to the dataclasses.isdataclass function, as discussed here.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.