通过什么动态替代机制，**Python** 非类对象在类继承列表中指定其参与类，从而影响方法解析顺序的计算？

问题的答案

问题的历史

随着 PEP 560 在 Python 3.7 中的采用，类型系统需要一种方法来使用像 List[int] 或 Generic[T] 这样的泛型作为基类。在此增强之前，尝试从参数化泛型继承会导致 TypeError，因为这些对象并不是实际的类，迫使开发人员寻找复杂的 metaclass 变通方法，这使得库设计变得复杂。

问题

当解释器处理类定义时，它必须使用 C3 线性化算法计算方法解析顺序 (MRO)。该算法要求所有基类必须是类。当基对象不是类而是泛型别名时，就会出现挑战；解释器需要一种协议来确定在构建 MRO 时应替换该别名的真实类，而不破坏继承语义。

解决方案

Python 引入了 __mro_entries__ 协议。当类创建遇到有此方法的基类时，它会调用 base.__mro_entries__(original_bases)，并期望返回一个类的元组。这些类将替换 MRO 计算中的原始基类。例如，typing.Generic 实现了此功能，可返回 (Generic,)，允许它作为基类的同时保持参数化逻辑的独立。

from typing import Generic, TypeVar

T = TypeVar('T')

# Generic[T] 不是一个类，但 __mro_entries__ 允许它充当一个类
class Container(Generic[T]):
    pass

# Container.__mro__ 包括 Generic，而不是 Generic[T]
print(Container.__mro__)  # (<class 'Container'>, <class 'typing.Generic'>, <class 'object'>)

生活中的情况

一个框架团队需要允许用户使用参数化泛型基类如 Model[UserType] 定义数据模型。他们最初的方法是使用自定义的 metaclass 来拦截类创建并提取类型参数，但这迫使用户在将框架与 Django 或 SQLAlchemy 模型结合时手动解决元类冲突。

他们考虑使用类装饰器在定义后重写类，但这种方法破坏了静态类型检查和 IDE 自动补全，因为变换发生在类型检查器分析源代码之后。另一种替代方案涉及 __init_subclass__，但这无法处理基本不是类的情况。

团队在他们的泛型工厂对象上实现了 __mro_entries__。当用户编写 class UserModel(Model[UserType]) 时，Model[UserType] 实例从其 __mro_entries__ 方法返回 (Model,)。这允许类正确地继承自 Model，同时工厂存储特定的类型参数以进行运行时验证。该解决方案消除了元类冲突，保留了完整的 IDE 支持，并维护了符合 C3 线性化算法的干净继承结构。

候选人常常忽视的内容

__mro_entries__ 是否影响运行时类型检查或 isinstance 行为？

候选人常常将 MRO 构造与实例检查混淆。__mro_entries__ 仅在类创建期间运行，以构建 __mro__ 元组。它对运行时的 isinstance() 或 issubclass() 检查没有影响。这些操作依赖于现有类的 __class__ 和 __bases__ 属性，而不是在类定义阶段发生的动态替代。

为什么 __mro_entries__ 返回元组而不是单个类？

元组返回类型适用于复杂的多重继承场景。尽管通常返回像 (Generic,) 的单元素元组，但该协议允许一个泛型参数同时隐含多个 mixins 的继承。Python 直接将该元组解包到基类列表中以进行 MRO 计算，因此返回 (A, B) 会使类同时继承 A 和 B，而不是原始的非类基类。

Python 对 __mro_entries__ 返回的类进行什么验证？

解释器严格验证返回的类是否形成有效的继承图。如果元组包含会创建不一致 MRO 的类——例如引入违反 C3 线性化约束的菱形继承冲突——Python 会在类创建过程中引发 TypeError。此验证确保动态替代无法规避语言的基本继承一致性规则。