Skip to content

allow overloads to be distinguished by contained type of a generic #4159

Closed

Description

@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.

Activity

  1. JelleZijlstra commented on Oct 25, 2017

    @JelleZijlstra
    Member

    This particular case could be handled by a TypeVar('T', int, str), unless I'm missing something. Is your actual use case more complicated?

  2. carljm commented on Oct 25, 2017

    @carljm
    MemberAuthor

    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).

  3. JukkaL commented on Oct 25, 2017

    @JukkaL
    Collaborator

    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.

  4. ilevkivskyi commented on Oct 26, 2017

    @ilevkivskyi
    Member

    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.

  5. JukkaL commented on Oct 26, 2017

    @JukkaL
    Collaborator

    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.

  6. ilevkivskyi commented on Jul 6, 2018

    @ilevkivskyi
    Member

    This is fixed on master now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions