FR: typechecking of @overload signatures?

[bukzor]

I'd really prefer if this failed to typecheck:

@overload
def g(x: float) -> complex: ...
@overload
def g(x: str) -> None: ...
def g(x: float | str) -> complex | None:
    del x
    return None

Would it be feasible for pyright to typecheck my function for each overload? At that point it could (should?) probably skip checking the implementation's annotated types (apart from ensuring they're compatible). The only wrinkle is that pyright should only mark code unused by all overloads as unused code.

Desired behavior:

├╴E  Overloaded implementation is not consistent with signature of overload 1
│      Type "(x: float) -> None" is incompatible with type "(x: float) -> complex"
│        Function return type "None" is incompatible with type "complex"
│          "None" is incompatible with "complex" Pyright (reportInconsistentOverload)

[erictraut]

No, this isn't practical. There are many problems with your proposal. I won't list them all here, but it is especially problematic for a just-in-time type checker like pyright where every expression must have precisely one type. Plus, errors reported during such a check would be confusing.

[bukzor]

Okay. Sadface. Thanks for considering! I'm very grateful for your time, so I understand if you elect to not reply to the rest of this: I can see that a naive approach would increase the runtime on a particular function by the number of overloads, but I'm having trouble seeing why it's infeasible... Even if each expression needs precisely one type, pyright could treat it as three functions with exactly the same body. As for UI concerns, any errors specific to a particular overload would appear indented under a "while evaluating overload 1" line. Further if pyright skips checking overloads for when a function has inconsistent overloads or fails to recheck with the implementation's, it will only show such errors when relevant.

…

On Thu, Aug 8, 2024, 2:07 PM Eric Traut ***@***.***> wrote: No, this isn't practical. There are many problems with your proposal. I won't list them all here, but it is especially problematic for a just-in-time type checker like pyright where every expression must have precisely one type. Plus, errors reported during such a check would be confusing. — Reply to this email directly, view it on GitHub <#8701 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE4KSDYLGMXSP3VEDMEGK3ZQO6YNAVCNFSM6AAAAABMHCPVI2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMRXHEYDOMI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[lucventurini]

Would the following be typed correctly by pyright?

from functools import singledispatch

@singledispatch
def g(x: None | float) -> complex | None:
    raise NotImplementedError(f"Invalid value: {x} (type {type(x)})")

@g.register
def _(x: None) -> None:
    return None

@g.register
def _(x: float) -> complex:
    return None

[erictraut]

@lucventurini, I'm not sure what you mean by "typed correctly". Pyright correctly generates a type violation error in your code because the last function is returning a None value when its return type is annotated as complex.

Pyright has no special-case handling of single dispatch, if that's what you're asking.

[lucventurini]

@erictraut, thank you for taking the time to review - I think that a better way of phrasing the question is, would singledispatch be a better alternative than overload for this class of cases?