在类创建过程中，**Python** 描述符通过哪种协议方法自动接收其分配的属性名称和包含类，并且当描述符在声明后附加到类时会出现什么限制？

问题的答案。

历史。

在 Python 3.6 之前，需要知道其属性名称的描述符依赖于自定义元类或手动类装饰器来扫描类字典并注入名称。这种方法冗长，容易出错，并且在复杂层次中产生元类冲突。PEP 487 在 Python 3.6 中引入了 __set_name__ 协议，以消除这种样板代码，允许解释器自动通知描述符。

问题。

描述符实例在类体执行期间创建，但那时它对绑定的变量名称或其所在的类没有内在的知识。此信息对于生成有意义的错误消息、在 ORM 系统中注册字段或构建序列化架构至关重要。如果没有外部通知，描述符保持匿名，迫使开发人员将属性名称作为字符串参数重复，违反了 DRY 原则。

解决方案。

当 type.__new__ 构造一个类时，它在 __prepare__ 返回的命名空间映射上进行迭代。对于每个具有 __set_name__ 方法的值，解释器调用 value.__set_name__(owner_class, attribute_name)。该方法接收正在构造的类和属性字符串，允许描述符存储这些元数据。然而， 如果描述符在类创建过程完成后（猴子补丁）分配给类属性，那么 __set_name__ 并不会自动调用，因为类型机制不再处于活动状态。

class TrackedDescriptor:
    def __set_name__(self, owner, name):
        self.owner = owner
        self.name = name
    
    def __get__(self, instance, owner):
        if instance is None:
            return self
        return f"{self.owner.__name__}.{self.name}"

class Model:
    field = TrackedDescriptor()

# Model.field.name == 'field'
# Model.field.owner == Model

生活中的情况

背景。

在开发配置管理库时，我们需要描述符来表示环境变量。当值缺失或无效时，错误必须指定类中的确切属性名称（例如，Config.database_url is required），而不仅仅是一个通用消息。

问题。

最初，用户必须手动指定名称：database_url = EnvVar('database_url')。这在重构过程中导致了字符串字面量和变量名称分歧，从而导致了难以理解的运行时错误。

考虑过的不同解决方案：

元类注入。 我们实现了一个 ConfigMeta，它检查 attrs 并在每个描述符上调用 attr.set_name(name)。虽然这个方法有效，但强迫所有用户类继承我们的元类，破坏了与其他使用其自身元类的库（如 abc.ABCMeta）的兼容性。它还为不熟悉元类的用户增加了认知负担。

类装饰器修补。 我们创建了一个 @config 装饰器，在类创建后迭代 cls.__dict__ 并修补名称。这避免了元类冲突，但需要选择性使用；忘记装饰器会导致描述符损坏。它还在类创建后运行，因此描述符不能在 __init_subclass__ 钩子中使用它们的名称，从而限制了 introspection 能力。

__set_name__ 协议。 我们向 EnvVar 描述符添加了 __set_name__。这不需要用户代码的任何更改，在类定义期间自动工作，并允许描述符在 __init_subclass__ 完成之前就知道其名称，从而实现早期验证。

选择的解决方案。

我们采用 __set_name__ 因为它为用户提供了零成本抽象，并与 Python 的原生数据模型集成。它完全消除了元类冲突问题。

结果。

API 变得声明式：database_url = EnvVar()。重构工具可以安全地重命名属性，错误消息保持准确。代码库减少了 150 行元类样板，并且我们观察到与配置键不匹配有关的错误报告减少了。

候选人通常错过的内容

__set_name__ 在类创建生命周期中的确切调用时机是什么？

它由 type.__new__ 在类体完成执行和命名空间字典填充后立即调用，但在对父类调用 __init_subclass__ 之前。这个时机至关重要，因为它允许描述符在子类初始化之前完成其状态。不在已经创建的类中添加属性时触发（例如，setattr(MyClass, 'new_attr', descriptor())），因为类创建协议已经结束。理解这种区别对于动态类操作至关重要。

为什么 __set_name__ 接收所有者类和名称作为参数，而不是从 self 中推断它们？

描述符实例独立于类存在；它可能在类创建之前实例化，并理论上可能分配给多个类（尽管很少见）。owner 参数确保描述符知道发生分配的特定类，对于正确处理继承是必要的。如果描述符在基类中定义，__set_name__ 将使用基类调用；如果在子类中重写并使用新实例，它将使用子类调用。这允许每个类注册，而不会在基类和派生类之间产生交叉污染。

__set_name__ 如何与 __set__ 和 __get__ 描述符协议方法交互？

__set_name__ 只是一个初始化钩子，不参与属性访问协议（__get__/__set__）。然而，它通过提供所需的上下文来使这些方法正常工作。一个常见的错误是认为 __set_name__ 在描述符被一个不重写它的子类继承时会再次被调用。由于使用相同的描述符实例，因此不会重新调用 __set_name__；因此，跟踪每个类状态的描述符必须使用 __init_subclass__ 或在 __get__ 中检查 owner 来处理继承，而不是仅依靠 __set_name__ 进行特定于子类的逻辑。