You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
allow overloads to be distinguished by contained type of a generic #4159
We've run into this limitation several times already at Instagram, and there aren't any nice workarounds for it. From a user point of view, the "empty list" rationale doesn't feel right; it seems like it should be possible to only error in specific calls with an unknown contained type.
There is some more discussion in the above-linked thread of how to handle this. In any case, I think it deserves tracking as a mypy limitation.
Yes, good point, I over-simplified the example. In our real cases the types involved are not always the same (there is a third overload for a different type of id, which still results in int keys in the returned mapping).
The old worry about empty lists is no longer valid. In the early days of mypy it was a bigger concern since @overload actually did runtime type dispatch, but now that it's only used for static checking we can relax the rules.
but now that it's only used for static checking we can relax the rules.
I think that it is not well specified in PEP 484 what overloads mean. I think the first step here should be to make a PR to PEP 484 with a detailed specification of how overloads work, what is allowed, and what is not.
I think that it is not well specified in PEP 484 what overloads mean. I think the first step here should be to make a PR to PEP 484 with a detailed specification of how overloads work, what is allowed, and what is not.
I agree that PEP 484 should specify how overloads should work, but I think that it's better to write the specification together with an implementation so that we can immediately test how the specification works in practice.
Activity
JelleZijlstra commentedon Oct 25, 2017
This particular case could be handled by a
TypeVar('T', int, str), unless I'm missing something. Is your actual use case more complicated?carljm commentedon Oct 25, 2017
Yes, good point, I over-simplified the example. In our real cases the types involved are not always the same (there is a third overload for a different type of id, which still results in int keys in the returned mapping).
JukkaL commentedon Oct 25, 2017
The old worry about empty lists is no longer valid. In the early days of mypy it was a bigger concern since
@overloadactually did runtime type dispatch, but now that it's only used for static checking we can relax the rules.ilevkivskyi commentedon Oct 26, 2017
I think that it is not well specified in PEP 484 what overloads mean. I think the first step here should be to make a PR to PEP 484 with a detailed specification of how overloads work, what is allowed, and what is not.
JukkaL commentedon Oct 26, 2017
I agree that PEP 484 should specify how overloads should work, but I think that it's better to write the specification together with an implementation so that we can immediately test how the specification works in practice.
Make overloads respect keyword-only args
Make overloads respect keyword-only args
Make overloads respect keyword-only args
Make overloads respect keyword-only args
ilevkivskyi commentedon Jul 6, 2018
This is fixed on master now.