MyPy虚拟类继承报类型不兼容 无显式继承接口类型安全方案

MyPy做静态类型检查时完全不执行Python运行时代码，所有继承关系判定只基于静态分析阶段可识别的显式声明，不会解析ABCMeta.__subclasshook__、自定义元类逻辑这类运行时动态生效的子类判定规则：

• 若类在定义时显式写了基类（如class Concrete(Base):），MyPy会直接将其判定为对应基类的子类型
• 若类没有显式声明继承关系，哪怕运行时issubclass(Concrete, Base)返回True，MyPy默认也不会认可二者的子类型关系，这就是自定义元类实现虚拟基类时静态检查报incompatible type错误的核心原因
• 对typing.Protocol的结构子类型匹配，是MyPy专门内置的静态分析规则，和运行时逻辑无关：检查阶段MyPy会逐字段比对类实现与Protocol定义的成员签名，只要结构符合就判定为子类型，不需要类显式继承Protocol。

不需要让具体类显式继承基类，可根据场景选择以下方案：

• 优先使用标准typing.Protocol实现结构子类型，针对测试中发现的Protocol缺陷，可通过对应方式规避，不需要放弃该方案：
  • 针对@runtime_checkable装饰的Protocol不支持非方法成员的issubclass校验问题：静态校验完全交给MyPy完成，运行时校验优先用isinstance判断实例；如果必须做类级别的运行时校验，可单独实现一个工具函数，遍历Protocol定义的__annotations__与方法成员做签名比对，不需要把校验逻辑耦合在元类中。
  • 针对Protocol不校验__init__方法签名的问题：MyPy对类构造函数的签名校验独立于Protocol匹配逻辑，如果需要约束实现类的初始化方法，可将构造逻辑单独抽为Factory类型的Protocol，专门约束可调用对象返回对应实例的签名，不要把__init__校验放在主接口Protocol中。
  • 针对装饰器差异识别问题：定义Protocol时严格按照接口要求标注@classmethod、@staticmethod标记，MyPy 1.0及以上版本已经可以正确区分类方法、静态方法、普通实例方法的签名差异，不会出现匹配错误。
• 如果需要保留自定义元类的运行时强校验能力，同时让MyPy识别子类型关系，可借助typing.TYPE_CHECKING常量做静态声明分支，示例代码如下：

  from typing import TYPE_CHECKING
  from abc import ABCMeta
  
  class Base(metaclass=ABCMeta):
      @classmethod
      def __subclasshook__(cls, subclass):
          # 保留原有自定义运行时签名校验逻辑
          required_attrs = ("required_method", "required_attr")
          return all(hasattr(subclass, attr) for attr in required_attrs)
  
  class Concrete:
      def required_method(self):
          pass
      required_attr = 1
  
  # TYPE_CHECKING在运行时固定为False，分支代码不会实际执行，不影响原有运行时逻辑
  if TYPE_CHECKING:
      Base.register(Concrete)
  

  这种方案下运行时完全走自定义的__subclasshook__校验逻辑，不需要Concrete显式继承Base，静态检查阶段MyPy会读取TYPE_CHECKING分支下的register调用，正确识别二者的子类型关系，不会抛出类型不兼容错误。
• 不建议使用Protocol配合@dataclass的强约束方案，也不需要强行给Protocol写@property定义，只要在Protocol类中直接标注属性的类型注解，MyPy就会正确校验实现类的属性类型是否匹配，不需要依赖dataclass的使用约定。

内容的提问来源于stack exchange，提问作者Sukombu