Support overloading with TypedDict #3612
Conversation
| if isinstance(actual, TypedDictType): | ||
| if isinstance(formal, TypedDictType): | ||
| # Don't support overloading based on the keys or value types of a TypedDict since | ||
| # that would be complicated and probably only marginally useful. |
There was a problem hiding this comment.
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.
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.
8000
| 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.
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.
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 Any for some overloads).
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
Fix #3609.