Skip to content
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

@overload - mypy thinks function signatures overlap #8656

Closed
Tinche opened this issue Apr 10, 2020 · 6 comments · Fixed by #16074
Closed

@overload - mypy thinks function signatures overlap #8656

Tinche opened this issue Apr 10, 2020 · 6 comments · Fixed by #16074

Comments

@Tinche
Copy link
Contributor

Tinche commented Apr 10, 2020

Hello,

I'm in the middle of introducing mypy to a medium-size codebase. Here's a simplified overload situation:

from typing import overload, List, Dict, Optional, Sequence, Union, Tuple


@overload
def f(a: List[Dict]) -> List[int]:
    ...


@overload
def f(a: List[Optional[Dict]]) -> List[Optional[int]]:
    ...


def f(
    a: Union[List[Dict], List[Optional[Dict]]]
) -> Union[List[int], List[Optional[int]]]:
    return [1]

Mypy claims: error: Overloaded function signatures 1 and 2 overlap with incompatible return types

The docs state: Two variants are considered unsafely overlapping when both of the following are true:

  1. All of the arguments of the first variant are compatible with the second.
  2. The return type of the first variant is not compatible with (e.g. is not a subtype of) the second.

But this doesn't seem to be the case. List[Dict] is not compatible with List[Optional[Dict]], no?

Mypy 0.770, Python 3.8.0.

@hauntsaninja
Copy link
Collaborator

hauntsaninja commented Sep 17, 2020

I think the issue is that eg, it's unclear what type foo({}) should be, which could lead to unsoundness. Closing, since I don't think this is a bug.

@hauntsaninja
Copy link
Collaborator

If you find the docs unclear, how would you feel about:

All of the arguments of the first variant are potentially compatible with the second.

People often tend to run into this when literal types are in the mix, so might be worth calling that out too. Can also try stealing language from the docstrings for is_unsafe_overlapping_overload_signatures or possibly is_callable_compatible's allow_partial_overlap parameter.

@rhshadrach
Copy link

@hauntsaninja Apologies, after realizing my mistake I deleted my post and opened issue #9451

@hauntsaninja
Copy link
Collaborator

hauntsaninja commented Sep 17, 2020

Took another look at the original example and read some code and I'm not so sure of anything anymore :-) So here, this issue is open again.
I think the error might just be a little lint-y when arguments merely sometimes overlap, serving as a reminder that static types don't really exist. Note that if you type ignore, you do get the inferred types you'd want.

# Or, to use a more concrete example, List[Union[A, B]] and List[Union[B, C]]

@hauntsaninja hauntsaninja reopened this Sep 17, 2020
jothan added a commit to zerospam/twisted that referenced this issue Oct 21, 2020
Sorry Glyph, I could not get overload to work for callRemoteString. I
hit this issue: python/mypy#8656
jothan added a commit to zerospam/twisted that referenced this issue Nov 9, 2020
Sorry Glyph, I could not get overload to work for callRemoteString. I
hit this issue: python/mypy#8656
@davidhalter
Copy link

I think this is reporting as designed. Optional[Dict] and Dict overlap, because the union of [X, Dict] and Dict overlaps. I would probably close this issue.

@hauntsaninja
Copy link
Collaborator

I think there are two documentation issues here:

  1. the current docs use "compatible" in a very vague way and it's not clear what the relationship is with subtyping
  2. this warning is more of a lint and there are valid reasons to ignore it, like in OP's example

hauntsaninja added a commit that referenced this issue Sep 10, 2023
A new error code was introduced in
#16061

As per #16068, we didn't previously
run doc builds on changes to errorcodes.py, causing tests to fail on
master when this was merged.

Renaming the code as per:
#16061 (comment) All
type ignores should be unsafe, so we should save the unsafe adjective
for things that are really unsafe. As it stands, there are many cases
where overloads overlap somewhat benignly.

Fixes #8656
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants