问题的答案

问题的历史

__mro_entries__ 协议在 Python 3.7 通过 PEP 560（“对类型模块和泛型类型的核心支持”）引入。在此增强之前，像 typing.List[int] 这样的泛型别名不能用作类定义中的基类，因为 type.__new__ 严格要求所有基类都是 type 的实例。这个限制迫使 typing 模块依赖脆弱的 metaclass 技巧，这些技巧难以维护且导致性能问题。该协议的设计旨在将基类的语法表达与它对继承图的语义贡献解耦，从而更好地支持泛型和工厂模式。

问题

当 CPython 处理类定义时，必须使用 C3 线性化算法计算方法解析顺序（MRO），以确保一致且可预测的方法查找层次。如果基对象不是类（例如，参数化泛型或配置对象），解释器缺乏必要的类型信息来正确地将新类放置于继承树中。简单地忽略这些对象会破坏 isinstance 检查和 super() 链，而完全拒绝它们又会阻止强大的元编程模式。核心挑战是允许这些非类对象在类构造阶段声明它们逻辑上代表哪些具体类。

解决方案

Python 现在在类创建时检查基元组中的每个项，看看是否有 __mro_entries__(self, bases) 方法。如果该方法存在，则会用原始基元组调用它，并且它必须返回一个实际类的元组以替换计算中的对象 MRO。返回的类将被视为如果它们已经明确列为基类。这种机制使得实例能够充当透明的占位符，在定义时解析为具体的类。

class ConfigurableMixin:
    def __init__(self, feature):
        self.feature = feature
    
    def __mro_entries__(self, bases):
        # 根据配置动态注入基类
        if self.feature == "logging":
            return (LoggingSupport,)
        return (BaseFeature,)

class LoggingSupport:
    def log(self, msg): print(msg)

class BaseFeature:
    pass

# 实例在 MRO 中被 LoggingSupport 替换
class Service(ConfigurableMixin("logging")):
    pass

print(LoggingSupport in Service.__mro__)  # True

生活中的情况

在一个大型异步网络框架中，开发者需要创建一个 DatabaseMixin 工厂，当用特定的数据库 URL 实例化时（例如，DatabaseMixin("postgresql://")），会自动将 ConnectionPool 和 AsyncSession 作为基类注入到用户的服务类中。困难在于 DatabaseMixin(...) 返回的是一个普通对象实例，而不是类，但它需要参与 MRO，就像开发者明确编写了 class UserService(ConnectionPool, AsyncSession) 一样。

解决方案 1：自定义 Metaclass 一种方法是创建一个元类，它扫描 __new__ 中的 bases 元组，识别 DatabaseMixin 实例，并在调用 super().__new__ 之前将它们替换为目标类。这允许精确控制，但引入了“元类冲突”问题：任何使用这个元类的服务不能从定义自己元类的其他类继承，例如某些 ORM 基类。此外，调试变得困难，因为类定义语法隐藏了复杂的转换，堆栈跟踪指向元类内部，而不是用户代码。

解决方案 2：创建后类装饰 另一种选择是使用在类创建后应用的类装饰器。该装饰器将在新类上手动复制 ConnectionPool 和 AsyncSession 的方法或使用 type.__setattr__ 注入它们。虽然这避免了元类传染，但从根本上破坏了 Python 的继承模型：isinstance(UserService(), ConnectionPool) 将返回 False，被复制方法中的 super() 调用将不正确解析，因为 MRO 实际上并不包含父类。这导致微妙的错误，框架工具无法识别服务为数据库功能。

解决方案 3：__mro_entries__ 协议 团队选择在 DatabaseMixin 返回的对象上实现 __mro_entries__。该方法根据解析的 URL 返回 (ConnectionPool, AsyncSession)。这个解决方案与 CPython 的原生类创建机制无缝集成。 MRO 被正确计算，isinstance 检查自然工作，并且没有元类冲突。工厂实例充当一个声明性占位符，在类构造期间融入正确的继承结构，保留 super() 语义并与多重继承兼容。

结果是一个干净、直观的 API，开发者可以编写 class OrderService(DatabaseMixin(postgres_url)):，自动获得连接池和会话管理功能，同时拥有正确的方法解析、完整的 IDE 支持，以及零运行时开销或继承冲突。

候选人常常忽略的内容

C3 线性化如何处理潜在的重复，当 __mro_entries__ 将基扩展为在继承列表中已经存在的类时？

当 __mro_entries__ 返回一个类，该类在基中也出现时（例如，如果一个工厂扩展到 (BaseA,) 而另一个显式基类是 Derived(BaseA)），Python 的 C3 算法将扩展的元组视为有效的基列表。算法然后合并这些列表，同时保持局部优先级顺序并确保单调性。由于 C3 旨在处理共同祖先，因此 BaseA 最终在 MRO 中仅出现一次，位于所有依赖于它的类之后，但在 object 之前。候选人通常错误地认为这会产生冲突或重复条目，但线性化过程自然去重，同时保持“子类优先于父类”的约束，从而确保一致的方法解析。

为什么 __mro_entries__ 不能访问正在创建的类，以及如果试图这样做会发生什么具体错误？

在类创建期间，type.__new__ 在类对象本身实例化之前对基对象调用 __mro_entries__。命名空间字典存在，但类对象尚未具有身份。如果实现尝试访问期望类的属性（例如，通过从外部作用域引用类名或尝试检查 bases，就好像它们已经绑定到新类一样），它将引发 NameError 或 AttributeError，因为绑定尚不存在。候选人经常假设他们可以检查类的最终状态或 __dict__ 来做出动态决策，但该方法只接收原始基元组作为参数，并必须依赖其内部状态来确定返回值。

通过 abc.ABCMeta.register() 将对象注册为 ABC 的虚拟子类是否会导致 ABC 出现在 MRO 中？

不。虚拟子类注册是一个运行时机制，它在 ABC 内部填充缓存，以进行 isinstance() 和 issubclass() 检查。它不会改变子类的 __mro__ 属性。当定义 MyClass(MyObject()) 并且 MyObject() 通过 __mro_entries__ 返回 (ConcreteBase,) 时，只有 ConcreteBase 出现在 MyClass.__mro__ 中。如果 ConcreteBase 被注册为 MyABC 的虚拟子类，则 isinstance(MyClass(), MyABC) 返回 True，但 MyABC 不会出现在 MyClass.__mro__ 中。候选人常常混淆虚拟子类与真正的继承，从而导致对为什么 super() 调用或 MRO 检查未反映 ABC 关系的困惑，或者为什么在继承中未通过的方法未能通过。

**Python** 实例可以通过什么方式指定其逻辑基类以参与方法解析顺序的计算？

问题的答案

生活中的情况

候选人常常忽略的内容

Python 实例可以通过什么方式指定其逻辑基类以参与方法解析顺序的计算？