Overloading bear confuses Mypy (and/or perhaps issue author)

Consider:

# test_case.py
from typing import Union, overload
from beartype import beartype

class MypySoConfuse:
    @overload
    def __getitem__(self, key: int) -> int:
        ...

    @overload
    def __getitem__(self, key: slice) -> tuple:
        ...

    @beartype  # <- comment this out and the warning goes away
    def __getitem__(self, key: Union[int, slice]) -> Union[int, tuple]:
        if isinstance(key, int):
            return 0
        else:
            return ()

This yields:

$ mypy --version
mypy 0.902
$ mypy test_case.py
test_case.py:14: error: Overloaded function implementation does not accept all possible arguments of signature 1
test_case.py:14: error: Overloaded function implementation does not accept all possible arguments of signature 2
Found 2 errors in 1 file (checked 1 source file)

If you comment out the @beartype decorator above, Mypy stops complaining. beartype is utter magic to me, and I—sadly—have not spent much (okay, any) time investigating a root cause, so I don’t know if this is a flaw in Mypy, or beartype, or just a fundamental incompatibility (no judgment, some people are just not meant to be together, and that’s okay).

[posita]

To my utter embarrassment (but not shock), this is indeed not only a Mypy issue, but a known one. Specifically: python/mypy#8393. No need to continue chewing valuable cognitive cycles keeping this issue open where it be known where said dragons and dark magic lie.

In summary, I’m closing this as fixed and suggesting that https://github.com/beartype/beartype/issues/39#issuecomment-871865394 et seq. should be treated as a non sequitur.

Thanks for all the attention!

[leycec]

Bwaha! I cackle madly like a scantily clad Heffalump huffing honey, pictured here.

I suspect we’ve now flung ourselves headlong from what was once an actual beartype issue into what is now a probable mypy issue. Yes, I am now bravely shifting the blame! Behold, evidence supporting my suspicious claims:

# test_case_part_deux.py
from typing import Any, Callable, TypeVar, Union, overload

T = TypeVar('T', bound=Callable[..., Any])
def identity(func: T) -> T:
    return func

class ThisTimeWithFeeling(tuple):  # <- uh-oh [dramatic pause], *inheritance* [dramatic discordant score]
    @overload
    def __getitem__(self, key: int) -> int:
        ...
    @overload
    def __getitem__(self, key: slice) -> tuple:
        ...
    # @beartype  # <- okay, comment *this* out and the warning goes away
    @identity  # <- okay, comment *this* out and the warning goes away
    def __getitem__(self, key: Union[int, slice]) -> Union[int, tuple]:
        if isinstance(key, int):
            return 0
        else:
            return (0,)

assert type(ThisTimeWithFeeling(range(10))[0]) == int
assert type(ThisTimeWithFeeling(range(10))[slice(2, 4)]) == tuple
print("success")

So, we’ve lazily replaced @beartype in the sad Eeyore example you graciously gave above with the most trivial possible decorator. Yup, it’s none other than the @identity decorator silently reducing to a noop by returning the passed callable unmodified as is. Excitement! Thrills! And… spills:

$ mypy test_case_part_deux.py
test_case_redux.py:18: error: Signature of "__getitem__" incompatible with supertype "tuple"
test_case_redux.py:18: error: Signature of "__getitem__" incompatible with supertype "Sequence"
Found 2 errors in 1 file (checked 1 source file)

Verily, mypy spaketh. It spaketh the exact same thing as when decorated by the @beartype decorator, actually. We infer that the actual decorator being applied doesn’t particularly matter. It’s something else that matters, which means either:

• mypy is doing it wrong. This is the likeliest and certainly most convenient explanation. I’ve found in life that other people are usually to blame for our own personal failings.
• You’re doing it wrong. I’m honestly out of my depth here, because my facility with type-hinting standards isn’t quite what one would hope from a runtime type-checking developer. I don’t think you’re doing wrong, but @overload intersects with dark magic and flamboyant dragons – so I can’t say for certain that you’re doing it right.

Would you mind reposting the @identity decorator example I just gave to mypy’s issue tracker? They should be able to clarify the situation. Until then, I’ll graciously ^🤮 leave this open. It’s possible, however unlikely, that we’ve still mistyped the @beartype decorator in some way.

^{please let this be mypy’s fault please please please}