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

Wrong checking of overload for keyword-only args #1907

Closed
dmoisset opened this issue Jul 19, 2016 · 3 comments
Closed

Wrong checking of overload for keyword-only args #1907

dmoisset opened this issue Jul 19, 2016 · 3 comments
Labels
bug mypy got something wrong false-positive mypy gave an error on correct code priority-1-normal topic-overloads

Comments

@dmoisset
Copy link
Contributor

While writing some stubs I found an issue that I simplified to the following:

from typing import overload

@overload
def f(*, out: str, flag: bool=False) -> str: ...

@overload
def f(*, flag: bool=False) -> bool: ...

reveal_type(f())  # I expect bool, get Any
reveal_type(f(flag=False))  # I expect bool, get Any
reveal_type(f(out="xxx"))   # I expect str, get str

The checker shows a

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

but actually the signatures do not overlap (there's no call that can match both the signatures).

Something that's also confusing is that if I change the order of the arguments like this

# Move the "out" argument to the end
@overload
def f(*, flag: bool=False, out: str) -> str: ...
@overload
def f(*, flag: bool=False) -> bool: ...

I stop getting the "signature overlap" error, but I still get the "Any" type on the first two example calls. Given that these arguments are keyword only their positions shouldn't matter at all

(Comes from python/typing#248 )

@euresti
Copy link
Contributor

euresti commented Dec 14, 2017

Very weirdly it's the kwonly that's causing issues:

This code has no issues:

@overload
def f(x: int) -> int: ...
@overload
def f(x: str) -> str: ...

But make those kwonly and boom:

@overload
def f(*, x: int) -> int: ...   # error: Overloaded function signatures 1 and 2 overlap with incompatible return types
@overload
def f(*, x: str) -> str: ...

Michael0x2a added a commit to Michael0x2a/mypy that referenced this issue Apr 14, 2018
This commit resolves python#1907.

Specifically, it turned out that support for non-positional args in
overload was never implemented to begin with. Thankfully, it also turned
out the bulk of the logic we wanted was already implemented within
`mypy.subtypes.is_callable_subtype`. Rather then re-implementing that
code, this commit refactors that method to support any kind of check,
instead of specifically subtype checks.

This, as a side-effect, ended up making some partial progress towards
python#4159 -- this is because unlike
the existing checks, `mypy.subtypes.is_callable_subtype` *doesn't* erase
types and has better support for typevars in general.

The reason this commit does not fully remove type erasure from overload
checks is because the new implementation still calls
`mypy.meet.is_overlapping_types` which *does* perform erasure. But
fixing that seemed out-of-scope for this commit, so I stopped here.
Michael0x2a added a commit to Michael0x2a/mypy that referenced this issue Apr 14, 2018
This commit resolves python#1907.

Specifically, it turned out that support for non-positional args in
overload was never implemented to begin with. Thankfully, it also turned
out the bulk of the logic we wanted was already implemented within
`mypy.subtypes.is_callable_subtype`. Rather then re-implementing that
code, this commit refactors that method to support any kind of check,
instead of specifically subtype checks.

This, as a side-effect, ended up making some partial progress towards
python#4159 -- this is because unlike
the existing checks, `mypy.subtypes.is_callable_subtype` *doesn't* erase
types and has better support for typevars in general.

The reason this commit does not fully remove type erasure from overload
checks is because the new implementation still calls
`mypy.meet.is_overlapping_types` which *does* perform erasure. But
fixing that seemed out-of-scope for this commit, so I stopped here.
Michael0x2a added a commit to Michael0x2a/mypy that referenced this issue Apr 23, 2018
This commit resolves python#1907.

Specifically, it turned out that support for non-positional args in
overload was never implemented to begin with. Thankfully, it also turned
out the bulk of the logic we wanted was already implemented within
`mypy.subtypes.is_callable_subtype`. Rather then re-implementing that
code, this commit refactors that method to support any kind of check,
instead of specifically subtype checks.

This, as a side-effect, ended up making some partial progress towards
python#4159 -- this is because unlike
the existing checks, `mypy.subtypes.is_callable_subtype` *doesn't* erase
types and has better support for typevars in general.

The reason this commit does not fully remove type erasure from overload
checks is because the new implementation still calls
`mypy.meet.is_overlapping_types` which *does* perform erasure. But
fixing that seemed out-of-scope for this commit, so I stopped here.
Michael0x2a added a commit to Michael0x2a/mypy that referenced this issue May 11, 2018
This commit resolves python#1907.

Specifically, it turned out that support for non-positional args in
overload was never implemented to begin with. Thankfully, it also turned
out the bulk of the logic we wanted was already implemented within
`mypy.subtypes.is_callable_subtype`. Rather then re-implementing that
code, this commit refactors that method to support any kind of check,
instead of specifically subtype checks.

This, as a side-effect, ended up making some partial progress towards
python#4159 -- this is because unlike
the existing checks, `mypy.subtypes.is_callable_subtype` *doesn't* erase
types and has better support for typevars in general.

The reason this commit does not fully remove type erasure from overload
checks is because the new implementation still calls
`mypy.meet.is_overlapping_types` which *does* perform erasure. But
fixing that seemed out-of-scope for this commit, so I stopped here.
@ilevkivskyi
Copy link
Member

The Any return is now fixed, but the overlap error still appears, so this is a false positive.

@ilevkivskyi ilevkivskyi added false-positive mypy gave an error on correct code topic-overloads labels May 17, 2018
@Michael0x2a
Copy link
Collaborator

This took way way longer to resolve then I originally thought it would take, but the above examples are working as expected now in master after f61c2ba.

There's still a few todos related to handling edge cases w.r.t. star args, optional args, and such in #5163 that needs to land before we can really call this done, but I'm going to close this mostly so I can prune the list of overload-related things I have left to do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug mypy got something wrong false-positive mypy gave an error on correct code priority-1-normal topic-overloads
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants