'Subclass of "A" and "B" cannot exist: would have incompatible method signatures' is usually wrong

[JelleZijlstra]

Mypy reports Subclass of "A" and "B" cannot exist: would have incompatible method signatures in many cases if given x: A, you run isinstance(x, B). However, this is often (always?) incorrect, as mypy does not account for subclasses that use method signatures that are subtypes of both classes.

Example (playground):

from typing import Never

class A:
    def f(self) -> int: return 0
class B:
    def f(self) -> str: return ""

class X(A, B):
    def f(self) -> Never: raise Exception

x: A = X()
if isinstance(x, B):  # E: Subclass of "A" and "B" cannot exist: would have incompatible method signatures
    reveal_type(x)    # E: Statement is unreachable
else:
    reveal_type(x)    # N: Revealed type is "__main__.A"

Here, mypy accepts the definition of a class X that is a subclass of A and B, yet also says that such a subclass cannot exist.

Any callable type is a subclass of (*args: object, **kwargs: object) -> Never, so incompatible method signatures cannot be a reason that a common subclass cannot exist.

It gets a little trickier with attributes. However, mypy accepts this class and then again claims it cannot exist (playground):

from typing import Never

class A:
    x: int
class B:
    x: str

class X(A, B):
    @property
    def x(self) -> Never: raise Exception
    @x.setter
    def x(self, x: int | str) -> None: pass

x: A = X()
if isinstance(x, B):  # E: Subclass of "A" and "B" cannot exist: would have incompatible method signatures
    reveal_type(x)    # E: Statement is unreachable
else:
    reveal_type(x)    # N: Revealed type is "__main__.A"

(Note though that pyright rejects this form of inheritance; possibly mypy should reject this too in the future if we revise how we treat inheritance of attributes.)

[sterliakov]

I agree with the reasoning here. What's your ideal approach to this?

In my experience this error usually grasps the intent correctly, detecting wrong isinstance checks during refactoring, and it is easy to silence otherwise (cast instead of ignore to avoid unreachable, but still). I'd really prefer to not see this check relaxed.

[JelleZijlstra]

Yes, pragmatically the current check is sometimes useful.

ty implements a variation of this by mirroring the CPython runtime logic for builtin classes. This is essentially to figure the "solid base" for each base class, which is the first base class that has a different size (at the C level) than its parent, and to reject multiple inheritance if there are multiple solid bases involved. This approach has the advantage that multiple inheritance is rejected only if it would also be rejected at runtime. However, they hardcode the "solid base" status for a small set of builtins, so their approach doesn't generalize well to types outside the stdlib. We could generalize this if we added a way for stubs to represent the solid base status of classes.

Mypy's current approach works sort of accidentally, in that most builtins that you might want to double-inherit from, and that are distinct solid bases, also happen to have methods that are incompatible with each other, so mypy rejects their double inheritance.

[ilevkivskyi]

(Note though that pyright rejects this form of inheritance; possibly mypy should reject this too in the future if we revise how we treat inheritance of attributes.)

And why is that? What is wrong with this example?

[JelleZijlstra]

And why is that? What is wrong with this example?

Probably shouldn't have mentioned that; it's not really relevant to this issue and I'm not interested right now in discussing the finer points of attribute inheritance. The point of this issue is that if mypy simultaneously claims a subclass of these classes can't exist, yet allows one to exist.