Python 描述符与 ORM：从查找规则到实战

用法也很直接，把描述符实例挂到类属性上：

class User:
    # 将 IntField 实例作为类属性，实现 age 的整数校验
    age = IntField()

# 测试正常赋值
user = User()
user.age = 30
print(user.age)  # 输出：30

# 测试赋值非整数，抛出异常
user.age = "abc"  # 抛出 ValueError: int value need

# 测试赋值负数，抛出异常
user.age = -5  # 抛出 ValueError: positive value need

这里有个坑比较容易踩。__set__ 里不要再写 instance.age = value，否则会再次触发描述符自己，直接递归到爆栈。把值存在描述符对象上，或者更常见地按实例隔离存储，才不会出事。上面这个例子只是为了说明机制，真正上线一般不会这么存。

数据描述符和非数据描述符

描述符分两类，差别不在名字，而在属性查找时的优先级。

数据描述符

同时实现了 __get__ 和 __set__ 的，就是数据描述符。上面的 IntField 就属于这一类。它的优先级高，会压过实例自己的属性。

非数据描述符

只实现 __get__ 的，是非数据描述符。Python 里的函数对象就是典型例子，因为函数实现了 __get__，绑定到实例后会变成方法。

非数据描述符的优先级更低，实例里已经有同名属性时，它就让路了。

属性到底怎么查

很多人记属性查找，会背成'先查实例，再查类，再查父类'。这在没涉及描述符时大体够用，但加上描述符后，顺序要更细一点。

user.age 这种访问，底层可以理解成 getattr(user, "age")，而真正的查找顺序大致是这样：

1. 先走 __getattribute__，这是入口，不管属性在不在都会先碰到它；
2. 先看类或基类里有没有同名数据描述符，有就直接调用 __get__；
3. 再看实例自己的 __dict__；
4. 然后查类或基类里的同名属性：如果是非数据描述符，就调用 __get__；如果只是普通类属性，就直接返回；
5. 如果还没找到，再走 __getattr__；
6. 还没有，就抛 AttributeError。

这个顺序里最关键的点是：数据描述符优先级最高，甚至能盖住实例属性。

数据描述符会覆盖实例属性

沿用上面的例子：

# 延续上文的 IntField 和 User
user = User()
user.age = 30  # 实例的__dict__为空，值保存在描述符实例中
print(user.__dict__)  # 输出：{}

# 手动给实例__dict__添加 age 属性
user.__dict__['age'] = "abc"

# 访问时仍调用数据描述符，因未给描述符赋值，会报错
print(user.age)  # 报错：IntField has no attribute 'value'

这里能看出一个很直观的结果：就算实例字典里塞了同名字段，只要类上的是数据描述符，访问时还是会先走描述符。

非数据描述符会被实例属性覆盖

如果只实现 __get__，情况就反过来了：

class NonDataIntField:
    # 仅实现__get__，非数据描述符
    def __get__(self, instance, owner):
        return 10

class User:
    age = NonDataIntField()

user = User()
# 实例赋值 age，覆盖非数据描述符
user.age = 30
print(user.age)  # 输出：30，而非描述符的 10

这也是非数据描述符在实际代码里常见的表现：它能提供默认行为，但一旦实例自己有值，就不再抢。

ORM 为什么离不开描述符

ORM 框架其实就是把'字段规则'和'对象属性'绑在一起。Django Model、SQLAlchemy 这些框架里的 CharField、IntegerField、EmailField，本质上都在做类似的事：把校验、默认值、数据库映射这些逻辑收进字段对象里。

通常会分成几层：

• __set__ 负责类型检查、范围检查之类的赋值约束；
• 初始化参数负责字段长度、主键、是否允许空值这些元信息；
• __get__ 负责取值时的行为控制。

这套设计的好处很实在：模型类写起来像普通对象，字段规则又可以统一管理。你不用在每个模型里复制一遍校验代码，框架也能把 Python 属性和数据库列对应起来。

小结

描述符解决的不是'属性访问太复杂'，而是'多个字段都要遵守同一套规则'这件事。property 适合少量场景，描述符更适合字段多、规则重复的模型代码。

理解它有两个重点：一是它怎么定义，二是它在属性查找里排第几。把这两点想明白，Django Model 或 SQLAlchemy 里的字段实现就不会那么神秘了。很多 ORM 的底层，确实就是这套机制在撑着。