allow overloads to be distinguished by contained type of a generic

[carljm]

This is a follow-up to the discussion beginning at python/typing#253 (comment)

Mypy's choice to not distinguish overload signatures by contained types rules out some natural API choices, e.g.

@overload
def map(ids: List[int]) -> Dict[int, MyObj]: ...

@overload
def map(ids: List[str]) -> Dict[str, MyObj]: ...

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.

[JelleZijlstra]

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]

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]

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.

[ilevkivskyi]

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.

[JukkaL]

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.