error when using overload and providing a default to callable parameter

[rcarpa]

Describe the bug
Hi team, the following code generates a warning and an error on pyright 1.1.314

warning: Type variable "_T" may go unsolved if caller supplies no argument for parameter "fnc"

and

error: Overloaded implementation is not consistent with signature of overload 2
    Type "(var: Unknown, fnc: (x: Unknown) -> Unknown = lambda x: x) -> Unknown" cannot be assigned to type "(var: str, fnc: (str) -> _T@convert = ...) -> _T@convert"
      Parameter 2: type "(str) -> _T@convert" cannot be assigned to type "(x: Unknown) -> Unknown"
        Type "(str) -> _T@convert" cannot be assigned to type "(x: Unknown) -> Unknown"
          Position-only parameter mismatch; expected 1 but received 0 (reportGeneralTypeIssues)

both of which seem incorrect to me, considering that the code provides an overload without the given argument; and that there is no parameter number mismatch.

Code or Screenshots

from typing import overload, Callable, TypeVar

_T = TypeVar('_T')


@overload
def convert(var: str) -> str:
    ...

@overload
def convert(var: str, fnc: Callable[[str], _T] = ...) -> _T:
    ...

def convert(var, fnc=lambda x: x):
    return fnc(var)


print(convert('5', int))

Is it a bug on the pyright side, or am I doing something incorrectly ?

[erictraut]

To eliminate the first warning, you should delete the = ... from the second overload. As you pointed out, the first overload already covers that case, so it's not necessary here. When you include it, pyright is correct in pointing out that the signature is problematic in that _T can remain unsolved.

The second error is arguably a bug. If you properly annotate the overload implementation, the error will go away. However, it should be possible to leave the implementation unannotated. The problem occurs because pyright is inferring the parameter type for fnc based on the default argument value. I'll investigate potential solutions to this one.

[erictraut]

I've addressed the second error. I decided to fix it by not inferring the type of an unannotated parameter based on a default value when that default value is a function (lambda or otherwise). This fix will be in the next release.

[rcarpa]

Thank you for the good pointers. It unblocked me in my annotation effort 🥳

[erictraut]

This is included in pyright 1.1.315, which I just published. It will also be included in this week's insiders release of pylance.