-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Support overloading with TypedDict #3612
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1032,6 +1032,125 @@ Point = TypedDict('Point', {'x': 1, 'y': 1}) # E: Invalid field type | |
[builtins fixtures/dict.pyi] | ||
|
||
|
||
-- Overloading | ||
|
||
[case testTypedDictOverloading] | ||
from typing import overload, Iterable | ||
from mypy_extensions import TypedDict | ||
|
||
A = TypedDict('A', {'x': int}) | ||
|
||
@overload | ||
def f(x: Iterable[str]) -> str: ... | ||
@overload | ||
def f(x: int) -> int: ... | ||
def f(x): pass | ||
|
||
a: A | ||
reveal_type(f(a)) # E: Revealed type is 'builtins.str' | ||
reveal_type(f(1)) # E: Revealed type is 'builtins.int' | ||
[builtins fixtures/dict.pyi] | ||
[typing fixtures/typing-full.pyi] | ||
|
||
[case testTypedDictOverloading2] | ||
from typing import overload, Iterable | ||
from mypy_extensions import TypedDict | ||
|
||
A = TypedDict('A', {'x': int}) | ||
|
||
@overload | ||
def f(x: Iterable[int]) -> None: ... | ||
@overload | ||
def f(x: int) -> None: ... | ||
def f(x): pass | ||
|
||
a: A | ||
f(a) # E: Argument 1 to "f" has incompatible type "A"; expected Iterable[int] | ||
[builtins fixtures/dict.pyi] | ||
[typing fixtures/typing-full.pyi] | ||
|
||
[case testTypedDictOverloading3] | ||
from typing import overload | ||
from mypy_extensions import TypedDict | ||
|
||
A = TypedDict('A', {'x': int}) | ||
|
||
@overload | ||
def f(x: str) -> None: ... | ||
@overload | ||
def f(x: int) -> None: ... | ||
def f(x): pass | ||
|
||
a: A | ||
f(a) # E: No overload variant of "f" matches argument types [TypedDict(x=builtins.int, _fallback=__main__.A)] | ||
[builtins fixtures/dict.pyi] | ||
[typing fixtures/typing-full.pyi] | ||
|
||
[case testTypedDictOverloading4] | ||
from typing import overload | ||
from mypy_extensions import TypedDict | ||
|
||
A = TypedDict('A', {'x': int}) | ||
B = TypedDict('B', {'x': str}) | ||
|
||
@overload | ||
def f(x: A) -> int: ... | ||
@overload | ||
def f(x: int) -> str: ... | ||
def f(x): pass | ||
|
||
a: A | ||
b: B | ||
reveal_type(f(a)) # E: Revealed type is 'builtins.int' | ||
reveal_type(f(1)) # E: Revealed type is 'builtins.str' | ||
f(b) # E: Argument 1 to "f" has incompatible type "B"; expected "A" | ||
[builtins fixtures/dict.pyi] | ||
[typing fixtures/typing-full.pyi] | ||
|
||
[case testTypedDictOverloading5] | ||
from typing import overload | ||
from mypy_extensions import TypedDict | ||
|
||
A = TypedDict('A', {'x': int}) | ||
B = TypedDict('B', {'y': str}) | ||
C = TypedDict('C', {'y': int}) | ||
|
||
@overload | ||
def f(x: A) -> None: ... | ||
@overload | ||
def f(x: B) -> None: ... | ||
def f(x): pass | ||
|
||
a: A | ||
b: B | ||
c: C | ||
f(a) | ||
f(b) | ||
f(c) # E: Argument 1 to "f" has incompatible type "C"; expected "A" | ||
[builtins fixtures/dict.pyi] | ||
[typing fixtures/typing-full.pyi] | ||
|
||
[case testTypedDictOverloading6] | ||
from typing import overload | ||
from mypy_extensions import TypedDict | ||
|
||
A = TypedDict('A', {'x': int}) | ||
B = TypedDict('B', {'y': str}) | ||
|
||
@overload | ||
def f(x: A) -> int: ... # E: Overloaded function signatures 1 and 2 overlap with incompatible return types | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm guessing this is the situation the comment I called out earlier refers to. I am okay with merging this now but I think it's at least debatable whether this should be allowed. What does PEP 544 (Protocols) do for similar situations? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Protocols actually allow overloads currently. For example: class A(Protocol):
x: int
class B(Protocol):
y: str
@overload
def f(x: A) -> int: ...
@overload
def f(x: B) -> str: ...
def f(x): ...
class C:
x: int
y: str
reveal_type(f(C())) # No error, but revealed type is ``Any`` It looks like this hits second part of issue #3295 (silently inferring In general I think we should support overloading on protocols, although arbitrary two protocols are obviously overlapping. This means however that we should decide on python/typing#253 |
||
@overload | ||
def f(x: B) -> str: ... | ||
def f(x): pass | ||
|
||
a: A | ||
b: B | ||
reveal_type(f(a)) # E: Revealed type is 'Any' | ||
reveal_type(f(b)) # E: Revealed type is 'Any' | ||
[builtins fixtures/dict.pyi] | ||
[typing fixtures/typing-full.pyi] | ||
|
||
|
||
-- Special cases | ||
|
||
[case testForwardReferenceInTypedDict] | ||
|
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.
Since you felt compelled to add a comment about that, how sure are you? What are the symptoms when someone tries to overload on two different TypedDict types? Will calls with any kind of dict then just fail with a vague error? Does this deserves opening a tracker issue to debate it further?
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.
Your comment below is correct -- signatures are considered to be overlapping. I created a new issue: #3618.
Note that there are other similar issues such as not being able to overload based on tuple structure, I think. I don't remember hearing user complaints about them, so this is perhaps not a high-priority issue. Anyway let's wait for user feedback before we do more work on this.