[FEAT or BUG] @overload and default value matches

[ego-thales]

Hello everyone,

In the following example, zero-argument call matches the first overload (with Literal[True]), despite the default value being False.

@overload
def f(x: Literal[True] = ...) -> int: ...
@overload
def f(x: Literal[False] = ...) -> str: ...
def f(x: bool = False) -> int | str: return 0 if x else ""
    
# Expected: OK / error / OK
f() + ""       # error: Unsupported operand types for + ("int" and "str")  [operator]
f(True) + ""   # error: Unsupported operand types for + ("int" and "str")  [operator]
f(False) + ""  # OK

Is this a bug or desired behaviour? The easy fix is the following (remove default value from the Literal[True] overload since it cannot be targetted.

@overload
def f(x: Literal[True]) -> int: ...
@overload
def f(x: Literal[False] = ...) -> str: ...
def f(x: bool = False) -> int | str: return 0 if x else ""
    

# Expected: OK / error / OK
f() + ""       # OK
f(True) + ""   # error: Unsupported operand types for + ("int" and "str")  [operator]
f(False) + ""  # OK

The problem with this fix, is that introduces dependance in the default value set in the actual definition of f. Indeed, if I were to change it from False to True, then I would have to rewrite the overloads.
I think it would be neat if the match took the default value into consideration, and I don't know if the fact that it is not here is a bug or a "non-feature".

What do you think about this?

Thanks for your time!
Élie

[A5rocks]

It's not a bug, mypy very much ignores defaults.

[sterliakov]

Duplicate of #18581, but this example manifests in obviously incorrect typechecking without definition-site errors.

[A5rocks]

Duplicate of #18581, but this example manifests in obviously incorrect typechecking without definition-site errors.

Are you sure? I'm under the impression this issue is mostly about selecting the right overload based on defaults, which mirrors issue 3737 (but is different) and is a feature request.

[sterliakov]

Are you sure?

Yes, almost definitely: leaving a couple of corner cases behind the scenes (there's a bit of variadic args/kwargs magic that doesn't apply here), mypy picks the first matching overload, and here the first one matches. If you swap the definitions, you should get the opposite behavior. Two overloads are unsafely overlapping due to common zero-values call signature with incompatible return types, [overloads-overlap] is designed to prevent exactly this from happening.

And there's nothing generic here to relate to 3737 - what am I missing?..

[ilevkivskyi]

Mypy never looks at overload implementation. Overloads are simply tried in order of appearance until one matches, you can flip order to achieve what you want.

As for selecting the overload depending on the default value, this is a non-starter (it may look simple, but it is actually really hard to implement in general), also it may be quite surprising when a matching overload is skipped for some reason.

[ego-thales]

Thanks for your answers!

I didn't know about [overload-overlap], I'm surprised mypy didn't raise it in my case. Is it only up with --strict? Or maybe it does not properly handle default value signatures?

[A5rocks]

I didn't know about [overload-overlap], I'm surprised mypy didn't raise it in my case. Is it only up with --strict? Or maybe it does not properly handle default value signatures?

[overload-overlap] is very forgiving! It's ultimately more on the linter side, so coming up with a set of rules that penalizes wrong code without penalizing correct code is ... kinda hard. (honestly I don't know the concrete conditions on what it's preventing beyond just general "this looks bad".)

I don't think it's worth adding code to check "are there two 0 arg overloads" because that would have to be quite a bit of extra implementation (current code just uses standard callable subtyping with a special subtype check but obviously the "standard callable subtyping" is what's passing this)