Mypyc runtime TypeError exceptions when you change inherited method to a staticmethod

[CoolCat467]

Crash Report

Using mypyc to compile an ABC subclass with @classmethod and implement it in a subclass as @staticmethod leads to runtime type exceptions.

checkers_minimax.py

from abc import ABC


class State:
    """State object."""


class MinimaxWithTT(ABC):
    @classmethod
    def terminal(cls, state: State) -> bool:
        return False

    def alphabeta_transposition_table(
        self,
        state: State,
    ) -> None:
        print(f"Just before crash {type(state) = }")
        self.terminal(state)


class CheckersMinimax(MinimaxWithTT):
    @staticmethod
    def terminal(state: State) -> bool:
        return False


def run() -> None:
    mm = CheckersMinimax()
    mm.alphabeta_transposition_table(State())


if __name__ == "__main__":
    run()

mypyc checkers_minimax.py
python -c "from checkers_minimax import run; run()"

Traceback

Traceback (most recent call last):
  File "<string>", line 1, in <module>
    from checkers_minimax import run; run()
                                      ~~~^^
  File "checkers_minimax.py", line 29, in run
    mm.alphabeta_transposition_table(State())
  File "checkers_minimax.py", line 18, in alphabeta_transposition_table
    self.terminal(state)
TypeError: checkers_minimax.State object expected; got abc.ABCMeta

To Reproduce

See above

Your Environment

• Mypy version used: mypy 1.17.1 (compiled: yes)
• Mypy command-line flags: See above
• Mypy configuration options from mypy.ini (and other config files): None
• Python version used: Python 3.13.3 (main, Jun 16 2025, 18:15:32) [GCC 14.2.0] on linux
• Operating system and version:

> uname -a
Linux ideapad 6.14.0-24-generic #24-Ubuntu SMP PREEMPT_DYNAMIC Sun Jun 15 11:18:07 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

• GCC version

> x86_64-linux-gnu-gcc --version
x86_64-linux-gnu-gcc (Ubuntu 14.2.0-19ubuntu2) 14.2.0
...

[CoolCat467]

Even smaller, not reliant on being ABC subclass or orignally being a classmethod, mypyc is just grabbing from class' metaclasses list or something for some reason

class State:
    """State object."""


class MinimaxWithTT:
    def terminal(self, state: State) -> bool:
        return False

    def alphabeta_transposition_table(
        self,
        state: State,
    ) -> None:
        print(f"Just before crash {type(state) = }")
        self.terminal(state)


class CheckersMinimax(MinimaxWithTT):
    @staticmethod
    def terminal(state: State) -> bool:
        return False


def run() -> None:
    mm = CheckersMinimax()
    mm.alphabeta_transposition_table(State())


if __name__ == "__main__":
    run()

Just before crash type(state) = <class 'checkers_minimax.State'>
Traceback (most recent call last):
  File "<string>", line 1, in <module>
    from checkers_minimax import run; run()
                                      ~~~^^
  File "checkers_minimax.py", line 26, in run
    mm.alphabeta_transposition_table(State())
  File "checkers_minimax.py", line 15, in alphabeta_transposition_table
    self.terminal(state)
TypeError: checkers_minimax.State object expected; got type

[sterliakov]

Nothing is "grabbing" a metaclass here. The issue is that mypyc is unable to handle overriding a method with staticmethod.

Normally mypy allows such overrides (despite them being unsafe when accessed on class objects). Probably we should add such a check under an optional code and enable it for mypyc compilation. Runtime cost of allowing such overrides would be prohibitively high, so the only thing missing here is an explicit compiler diagnostic.

[sterliakov]

Note that this override isn't completely safe at runtime either:

class A:
    def foo(self) -> None: pass

class B(A):
    @staticmethod
    def foo() -> None: pass

def fail(a: A) -> None:
    type(a).foo(a)

fail(B())

AFAIC this was decided as an obscure case where practicality beats purity, and I agree with this analysis. You can come up with more sensible code sample that can appear in a real program (something taking type[A] and calling a method of it on some instance), but this fancy polymorphism is still too uncommon to detect.

So this shouldn't be a mypy error enabled by default, an optional error code would be the best course of action IMO.