Can't overload __add__ for subclass

[gvanrossum]

Consider the following working code:

from typing import overload

class S:
    @overload
    def __add__(self, arg: 'A') -> 'S': ...
    @overload
    def __add__(self, arg: 'S') -> 'S': ...

class A(S):
    @overload
    def __add__(self, arg: 'A') -> 'A': ...
    @overload
    def __add__(self, arg: 'S') -> 'S': ...

Think of 'S' as 'str' and 'A' as 'ascii', a subclass used only for literals containing only ASCII characters. The idea is that adding ASCII to ASCII produces ASCII, but all other combinations produce just strings.

The subclass 'A' redefines the method __add__ to express this idea. This version of the code works. However, the base class contains redundant overloads: 'A' is a subclass of 'S' so the base class is equivalent to the following, which doesn't use overloads:

class S:
    def __add__(self, arg: 'S') -> 'S': ...

And here's the rub: with this definition of 'S', the definition of __add__ in 'A' (still using overloads) is rejected:

__tmp__.py:10: error: Signature of "__add__" incompatible with supertype "S"

(The error points to the first @overload, but it seems to apply to the entire set of overloads.)

Now here's the real rub: if I change __add__ consistently to method, the error goes away!

[UPDATE I can't repro this for __radd__ -- it seems unique to __add__.]

[gvanrossum]

@JukkaL Any idea what could be causing this?

[JukkaL]

It's this code in checker.py (in check_override):

        elif (not isinstance(original, Overloaded) and
              isinstance(override, Overloaded) and
              name in nodes.reverse_op_methods.keys()):
            # Operator method overrides cannot introduce overloading, as
            # this could be unsafe with reverse operator methods.
            fail = True         <==== here

This seems to be overly conservative. I'd suggest just removing the check and seeing if this breaks something. I'm sure there is some edge case where things can go wrong, but it's probably not important enough to worry about it.

[gnprice]

Given that it applies only in the special case of a method like __add__, I think this is clearly a bug of some nature.

[elazarg]

@JukkaL there is a test case for this behavior, which I don't understand. I left some questions there (let me know if that's not acceptable). Or perhaps that's what you mean when you say it's too conservative.

[henryJack]

Any updates on this? Overloaded methods like __mul__ and __add__ still mess with mypy. e.g.

class A:
    def __mul__(self, other: A) -> 'B':
        ...
    def __add__(self, other: A) -> 'C':
        ...

type(A() * A()) is B and type(A() + A()) is C but mypy still throws error.

If you want types, the work around would be to manually define the add and multiply methods to the class.

class A:
    def multiply(self, other: A) -> 'B':
        ...
    def add(self, other: A) -> 'C':
        ...

...then doing A().add(A()) and A().multiple(A()) will make mypy happy

[gvanrossum]

Can you show a complete example? I tried this and it gives me the expected output, no errors:

class B: pass
class C: pass
class A:
    def __mul__(self, other: A) -> 'B':
        ...
    def __add__(self, other: A) -> 'C':
        ...
reveal_type(A()*A())  # B
reveal_type(A()+A())  # C

[ilevkivskyi]

Superseded by #4985