It's hard to write custom operators after the change of #4880

[Azureblade3808]

Here's what I would typically write custom operators for a set of classes (a root class and several known subclasses)--

from __future__ import annotations

from typing import overload

class Complex:
    ...

    @overload
    def __add__(self: Integral, right: Integral | int, /) -> Integral:
        ...

    @overload
    def __add__(self: Real, right: Real | float, /) -> Real:
        ...

    @overload
    def __add__(self: Complex, right: Complex | complex, /) -> Complex:
        ...

    def __add__(self, right: Complex | complex, /) -> Complex:
        return _add(self, right)

    @overload
    def __radd__(self: Integral, left: int, /) -> Integral:
        ...

    @overload
    def __radd__(self: Real, left: float, /) -> Real:
        ...

    @overload
    def __radd__(self: Complex, left: complex, /) -> Complex:
        ...

    def __radd__(self, left: complex, /) -> Complex:
        return _add(left, self)

class Real(Complex):
    ...

class Integral(Real):
    ...

def _add(left: Complex | complex, right: Complex | complex) -> Complex:
    assert not (isinstance(left, complex) and isinstance(right, complex))

    raise NotImplementedError

For simplicity, only addition is illustrated here.

After #4880, without any type: ignores, the code would become --

from __future__ import annotations

from typing import overload
from typing_extensions import override

class Complex:
    ...

    def __add__(self, right: Complex | complex, /) -> Complex:
        return _add(self, right)

    def __radd__(self, left: complex, /) -> Complex:
        return _add(left, self)

class Real(Complex):
    ...

    @overload
    def __add__(self, right: Real | float, /) -> Real:
        ...

    @overload
    def __add__(self, right: Complex | complex, /) -> Complex:
        ...

    @override
    def __add__(self, right: Complex | complex, /) -> Complex:
        return super().__add__(right)

    @overload
    def __radd__(self, left: float, /) -> Real:
        ...

    @overload
    def __radd__(self, left: complex, /) -> Complex:
        ...

    @override
    def __radd__(self, left: complex, /) -> Complex:
        return super().__radd__(left)

class Integral(Real):
    ...
    
    @overload
    def __add__(self, right: Integral | int, /) -> Integral:
        ...

    @overload
    def __add__(self, right: Real | float, /) -> Real:
        ...

    @overload
    def __add__(self, right: Complex | complex, /) -> Complex:
        ...

    @override
    def __add__(self, right: Complex | complex, /) -> Complex:
        return super().__add__(right)

    @overload
    def __radd__(self, left: int, /) -> Integral:
        ...

    @overload
    def __radd__(self, left: float, /) -> Real:
        ...

    @overload
    def __radd__(self, left: complex, /) -> Complex:
        ...

    @override
    def __radd__(self, left: complex, /) -> Complex:
        return super().__radd__(left)

def _add(left: Complex | complex, right: Complex | complex) -> Complex:
    assert not (isinstance(left, complex) and isinstance(right, complex))

    raise NotImplementedError

As we can see, the overrides in subclasses exist merely to provide method signatures, and they seem very repeating.

Even by using type: ignores, there would be a lot of lines to modify because of the number of all kinds of operators. And as the issue is reported in reportGeneralTypeIssues category, it would be preferred that the self line be wrapped as an individual line to be ignored, which would cause additional nuisance.

I'd expect #4880 be reverted, or a new category be created for it.

Edit

Use better samples and re-word.

[erictraut]

Pyright already implemented this check for non-overloaded methods. I noticed that mypy was reporting this error for overloaded methods as well, which is what prompted me to implement it. Mypy generates errors for your code sample above.

I can see some utility for the check, but I can also see how it can produce false positives in some cases.

I think our options are:

1. Remove the check entirely for both overloaded and non-overloaded methods.
2. Remove the check for overloaded methods only.
3. Leave the check in place for both overloaded and non-overloaded methods (i.e. keep it as is).

I don't like the idea of creating a separate rule specifically for this check. It's too specific for its own rule. Plus, it's not clear whether it should be on by default in "basic" or "strict" mode. If it's not on by default in either, then it's not worth having the rule at all (option 1 or 2).

My inclination is to go with option 2, which simply reverts the recent change. The change was prompted not by a user request but by my own observation that mypy was producing an error that pyright didn't detect. But that's probably not a good enough justification for the change if it's causing problems for existing pyright users.

[erictraut]

I've gone with option 2. This will be included in the next release.