如何确保每个对象实例自动拥有可配置的 `__prop__` 属性？

Question

如何确保每个对象实例自动拥有可配置的 `__prop__` 属性？ 这是一个典型的元编程与实例初始化协同设计问题。常见误区是直接在类体中定义 `__prop__ = {}`，但这会导致所有实例共享同一字典（浅拷贝陷阱）；若在 `__init__` 中手动赋值，又易被子类遗忘或覆盖。更深层挑战在于：`__prop__` 需支持动态键值、类型校验、变更通知等可配置能力，且必须对 `getattr`/`setattr` 透明——即不破坏常规属性访问语义。此外，在继承链中需保证父类与子类 `__prop__` 独立隔离，同时兼容数据类（`@dataclass`）、`__slots__` 及 `__dict__` 禁用场景。若采用描述符或 `__getattribute__` 拦截方案，又面临性能损耗与递归调用风险。因此，核心难点在于：**如何在零侵入、高兼容、强隔离的前提下，于实例创建瞬间自动、独立、可扩展地注入并托管 `__prop__` 属性？**

Answer 1

```html

一、问题本质剖析：为什么 __prop__ 不能“简单定义”？

表面看是初始化问题，实则是 Python 对象模型（Object Model）与元编程边界的深度博弈。Python 中类体语句在类定义时执行，__prop__ = {} 创建的是类属性（class-level），所有实例共享引用——这是典型的 可变默认参数陷阱 的变体。而 __init__ 手动赋值虽可行，却违背“零侵入”原则：子类若未显式调用 super().__init__() 或重写构造逻辑（如 @dataclass 自动生成 __init__），__prop__ 即刻失效。更严峻的是，在 __slots__ 场景下，__dict__ 被禁用，常规实例字典注入路径彻底阻断。

二、兼容性约束矩阵：四大关键场景的交叉验证

场景	是否支持 __prop__ 独立实例化	是否破坏 getattr/setattr 语义	是否兼容 __slots__	是否兼容 @dataclass
类体直接赋值	❌ 共享引用	✅ 透明	✅（但无意义）	✅（但污染类属性）
__init__ 手动创建	✅（需子类严格配合）	✅	✅（需手动管理）	❌（@dataclass 覆盖 __init__）
描述符方案	✅（每个实例独立）	❌（需重写 __get__/__set__）	✅	✅（但需注册时机精准）
__new__ 拦截 + 实例字典注入	✅（最底层控制）	✅（不干涉访问链）	✅（可动态绑定）	✅（在 __init__ 前完成）

三、元编程破局：基于 __new__ 的实例级托管协议

核心思想：在对象内存分配后、初始化前，由元类统一注入隔离的 __prop__ 容器，并将其与实例生命周期强绑定。此方案绕过 __init__ 的不确定性，天然兼容 @dataclass（其 __init__ 在 __new__ 后执行），且对 __slots__ 友好——因 __prop__ 不存于 __dict__，而采用 object.__setattr__(inst, '__prop__', ...) 强制写入实例私有命名空间。

class PropMeta(type):
    def __call__(cls, *args, **kwargs):
        # 1. 分配实例（触发 __new__）
        inst = super().__call__(*args, **kwargs)
        # 2. 零侵入注入：即使 __slots__ 存在也生效
        object.__setattr__(inst, '__prop__', PropContainer())
        return inst

class PropContainer:
    def __init__(self):
        self._data = {}
        self._validators = {}
        self._observers = {}

    def __setitem__(self, key, value):
        if key in self._validators:
            self._validators[key](value)
        old = self._data.get(key)
        self._data[key] = value
        if old != value and key in self._observers:
            for cb in self._observers[key]:
                cb(old, value)

四、工业级增强：动态配置与透明访问协议

为达成“对 getattr/setattr 透明”，需在实例层级实现属性代理。我们不重写 __getattribute__（避免递归与性能损耗），而是利用 Python 3.9+ 的 __set_name__ 协议与描述符组合，在元类中自动将 __prop__ 绑定为“属性转发器”。当访问 inst.xxx 时，若 xxx 不在实例 __dict__ 或类 MRO 中，则委托至 inst.__prop__ 查找——该行为通过定制化的 __getattr__ 实现（仅在属性缺失时触发，无性能惩罚）：

class PropEnabled(metaclass=PropMeta):
    def __getattr__(self, name):
        if name == '__prop__':
            # 避免无限递归：确保 __prop__ 已存在
            return object.__getattribute__(self, '__prop__')
        try:
            return self.__prop__[name]
        except KeyError:
            raise AttributeError(f"'{type(self).__name__}' object has no attribute '{name}'")
    
    def __setattr__(self, name, value):
        # 仅当 __prop__ 已初始化且 name 非保留名时，写入 __prop__
        if (hasattr(self, '__prop__') 
            and name not in ('__prop__', '__dict__', '__slots__')
            and not hasattr(type(self), name)):
            self.__prop__[name] = value
        else:
            super().__setattr__(name, value)

五、继承与隔离保障：MRO 感知的 Prop 命名空间

为确保父类与子类 __prop__ 完全隔离，引入“作用域哈希”机制：元类在 __new__ 中根据当前类及其完整 MRO 计算唯一标识符，作为 __prop__ 内部存储的根命名空间。例如：ChildClass 继承 ParentClass，二者 __prop__['config'] 互不可见。此设计同时支持多继承下的线性化隔离，且不影响外部访问语法——用户仍使用 inst.config，内部自动路由到对应命名空间。

graph TD
    A[实例创建] --> B[元类 __call__]
    B --> C{是否首次初始化 __prop__?}
    C -->|是| D[计算 MRO 哈希 → scope_id]
    C -->|否| E[复用已有 scope_id]
    D --> F[创建 PropContainer scope_id]
    F --> G[object.__setattr__ 写入 __prop__]
    G --> H[返回实例]

```