Python类机制进阶：属性访问、描述符与元类深入解析

看到这个标题可能有人会问面向对象编程写到第四篇还能讲什么基础语法、类定义、继承、多态前面都过了一遍再往下挖就要碰到 Python 类机制的内裤了。这一篇我打算聊的东西既基础又经常被忽略——属性访问机制、property、描述符、元类以及抽象基类。把这些搞明白你再去翻 Django、SQLAlchemy、pandas 的源码会发现很多卡了很久的疑问突然就通了而不是停留在这个库这么写挺神奇的层面。这篇适合两类人一是已经能写面向对象代码但每次用self.xxx、property都是照着模板抄没想过底层到底发生了什么的同学二是想读懂开源框架源码却被各种魔法劝退的同学。面向对象编程这条路写到这一篇算是真正开始摸到 Python 的类机制硬核了。1. 从属性访问开始重新理解类与实例的关系先做一个简单的实验。定义一个只有类变量的类然后分别通过类和实例去读属性、写属性观察结果。很多学了几个月 Python 的人对下面这段代码的输出都判断不准。class User: role member u1 User() u2 User() print(u1.role) # member u1.role admin print(u1.role) # admin print(u2.role) # member print(User.role) # memberu1.role admin执行完之后u2.role依然是memberUser.role也还是member。这里的关键在于赋值操作没有修改类变量而是往 u1 自己的命名空间里塞了一个新键。很多人对对象属性的理解是模糊的觉得对象上面挂着一些变量这种理解在简单场景够用但遇到描述符、元类时会彻底崩盘。所以这一章先把地基打牢。1.1 一个 obj.attr 背后到底发生了什么当你写u1.role时Python 的查找并不是很多人以为的那样先找实例再找类真实流程是这样的在type(u1)也就是User类里找role这个键。如果找到的是一个数据描述符直接调用它的__get__方法实例 dict 根本没机会参与如果类里没找到数据描述符再去u1.__dict__里找实例属性实例 dict 里也没有回到类里找如果找到的是一个非数据描述符调用它的__get__方法类里也没有就沿着 MRO 找基类重复上面的检查所有地方都找不到抛AttributeError。这个顺序里最反直觉的地方是第一步数据描述符的优先级高于实例__dict__。这意味着如果你在类里定义了一个实现了__set__的描述符那么就算实例 dict 里存在同名属性访问时也走描述符。这一点是property能正常工作的根基也是后面第四节的重点先在这里埋个伏笔。1.2__dict__对象属性的事实存储地普通用户自定义类的实例属性最终都存在instance.__dict__这个字典里。类是对象类属性也存在User.__dict__里只不过它返回的是一个mappingproxy只读不能直接像普通字典那样增删键。用__dict__看前面那个例子一切一目了然print(u1.__dict__) # {role: admin} print(u2.__dict__) # {} print(User.__dict__) # {__module__: __main__, role: member, __dict__: attribute __dict__ of User objects, ...}u1.role admin这一句的本质就是在u1.__dict__里写入{role: admin}而不是去改User.__dict__里的role。理解到这里类变量和实例变量的区别就基本清楚了。如果希望实例不维护__dict__可以定义__slots__。它的作用是告诉 Python这个类的实例只需要这几个属性槽位从而节省内存也禁止往实例上随意挂新属性。class Point: __slots__ (x, y) p Point() p.x 1 p.z 2 # AttributeError: Point object has no attribute z__slots__在需要创建大量对象的场景比如数据解析、游戏实体、机器学习样本容器里内存收益非常可观。我见过一个项目把几十万个小对象从默认__dict__改成__slots__后内存直接下降了三成以上。代价是代码灵活性降低所以一般只有确定对象结构稳定时才用。1.3 方法查找为什么 obj.method() 得到的是绑定方法函数在类里定义后本身也是类的属性。访问User.hello拿到的是普通函数访问g.hello拿到的却是绑定方法。但它们的底层是同一个函数对象区别在于函数对象实现了描述符协议。class Greeter: def hello(self): return hi g Greeter() print(Greeter.hello) # function Greeter.hello at ... print(g.hello) # bound method Greeter.hello of __main__.Greeter object at ...函数对象有一个__get__方法。类访问时__get__返回原函数实例访问时__get__返回一个把实例绑定到第一个参数上的方法对象。这意味着g.hello()等价于Greeter.hello(g)。classmethod、staticmethod、property 以及我们后面要讲的描述符本质都是在利用这套协议。方法只是属性的一种这句话很多人第一次听会愣一下但想明白之后Python 的对象模型就清楚了一半。2. 类变量与实例变量命名空间的博弈与共享陷阱上一章用一条查找链解释了属性从哪来这一章专门讲类变量与实例变量的博弈。类变量定义在类的命名空间里被所有实例共享实例变量定义在实例的命名空间里每个实例各有一份。两者靠赋值行为触发理解赋值行为是避开大量深坑的关键。2.1 两种变量的本质区别类变量写在类体里实例变量写在__init__里通过self.xxx ...定义。赋值那一刻行为完全不同User.role admin修改的是类命名空间u1.role admin修改的是实例命名空间等价于u1.__dict__[role] admin。当你要读取u1.role时按第一节的查找链实例 dict 里有就直接返回没有就找类。这种设计的好处是所有实例可以共享同一个默认值不用每个实例都复制一份坏处是如果共享的是可变对象一个实例改了其他实例全变。2.2 可变对象共享经典坑几乎每个 Python 学习者都踩过这个坑class ShoppingCart: items [] cart1 ShoppingCart() cart2 ShoppingCart() cart1.items.append(apple) print(cart2.items) # [apple]问题出在哪items []是类变量这个列表对象只有一个被所有实例共享。cart1.items.append(...)是往这个共享列表里加元素没有触发赋值所以 cart1 和 cart2 看到的是同一个对象。正确的写法是把可变对象放进__init__class ShoppingCart: def __init__(self): self.items [] cart1 ShoppingCart() cart2 ShoppingCart() cart1.items.append(apple) print(cart2.items) # []为什么__init__里用self.items []就没问题因为触发的是实例命名空间写入每个实例在初始化时都创建了自己的空列表。这个坑的本质是读属性和写属性走了完全不同的路径——读会回溯到类写只落在实例上。顺带提一个相关度极高的坑可变默认参数。def add_item(self, item, items[])这种写法默认列表是在函数定义时创建的被所有调用共享效果和上面的类变量陷阱一样。除非你明确知道自己在干什么否则默认参数一律用None加守卫。2.3 什么时候大胆用类变量讲了坑不是让你从此禁用类变量。类变量在下面几类场景里是非常合理的实践常量定义class RetryPolicy: MAX_RETRY 3 BASE_INTERVAL 1.0子类可以覆盖这些常量值实现不同策略这是类变量的经典玩法。全局共享的统计信息比如给所有实例计数class Animal: total 0 def __init__(self): Animal.total 1类级别的配置项或缓存所有实例共享一份读取结果。关键判断标准只有一条这个值在逻辑上属于这一类对象而非某一个对象吗如果是就用类变量如果每个实例需要独立状态就放进__init__。另外提一下私有化Python 没有真正的 private约定用单个下划线_name表示内部使用不要乱碰用双下划线__name触发 name mangling变成_ClassName__name目的是避免子类意外覆盖。但不要指望它做安全隔离它只是命名改写。3. 驾驭 property把方法伪装成属性的艺术理解了属性查找就该聊聊 property 了。property可能是 Python 里最常用也最容易被低估的工具。它让你在外部 API 不变的情况下给属性访问插入逻辑是封装思想落到实处的第一课。3.1 从裸属性到校验逻辑假设你写了一个温度类一开始很朴素class Temperature: def __init__(self, celsius): self.celsius celsius后来需求变了赋值时如果温度低于绝对零度必须报错。如果直接暴露celsius属性你只能在每个赋值的地方加判断而且后续可能还有别的地方赋值迟早漏掉。最简单的办法是改成手动 getter/setterclass Temperature: def __init__(self, celsius): self.set_celsius(celsius) def get_celsius(self): return self._celsius def set_celsius(self, value): if value -273.15: raise ValueError(温度不能低于绝对零度) self._celsius value能用但调用方式从temp.celsius变成了temp.get_celsius()破坏了已有调用方的代码。property 的优雅之处在于外部继续保持temp.celsius 30的写法内部走校验逻辑。class Temperature: def __init__(self, celsius): self.celsius celsius property def celsius(self): return self._celsius celsius.setter def celsius(self, value): if value -273.15: raise ValueError(温度不能低于绝对零度) self._celsius value现在temp.celsius 30会自动触发 settertemp.celsius读取触发 getter。对调用方来说API 没有任何变化但行为从裸赋值变成了带校验的赋值。这就是封装的意义你可以在不改变接口的前提下修改内部实现。3.2 property 的完整形态getter/setter/deleterproperty只是property(fget, fset, fdel, doc)这个类的语法糖。完整形态还可以定义删除时的行为class Config: def __init__(self): self._value None property def value(self): return self._value value.setter def value(self, new_value): self._value new_value value.deleter def value(self): raise PermissionError(这个属性不允许删除)除了校验property 最常见的用途是计算属性。比如一个矩形类class Rectangle: def __init__(self, width, height): self.width width self.height height property def area(self): return self.width * self.heightarea不是一个存储属性而是每次实时计算的结果。这种写法比self.area ...好在哪里如果宽高变化area自动跟着变化不会出现缓存过期的问题。3.3 什么时候该用 property我的经验是不要给所有私有属性都写 property。有些初学者听说了封装就把每个_name都配一个 property结果是类膨胀、样板代码一堆纯属过度设计。合理的判断标准如下外部需要一个看起来像属性的接口但内部有计算、校验、转换逻辑项目已经上线一个裸属性要补业务规则但不想改调用方属性的读取成本高希望延迟计算或加缓存。不符合这些情况时直接暴露属性没有任何问题。Python 社区一贯的哲学是我们都是成年人了不是所有字段都需要掩体。我在实际项目里用得比较多的一个姿势是先用裸属性写等真的出现了每次赋值/读取都要带逻辑的需求再封装成 property。如果一开始就预测所有可能的约束往往会写出一堆永远走不到的分支。3.4 property 的底层是描述符property本身就是用描述符协议实现的。它实例化时接收的 fget、fset、fdel 三个函数被保存下来当作为类属性存在时访问会触发描述符的__get__、__set__、__delete__方法从而把操作转发给保存的三个函数。所以你真正理解属性机制后property 不再是装饰器魔法而是描述符的一个内置实现。这引出了整个系列最关键的一章。4. 描述符协议Python 类设计的地基也是属性机制的总开关描述符是 Python 面向对象机制里最被低估、但也是最有分量的概念。函数、classmethod、staticmethod、property、甚至super()的工作都建立在描述符协议上。框架作者喜欢在描述符层做文章因为它是拦截属性访问这种最基础操作的总开关。4.1 描述符协议是什么一个类如果实现了下面任何一个方法它就是一个描述符类class Descriptor: def __get__(self, instance, owner): ... def __set__(self, instance, value): ... def __delete__(self, instance): ...当描述符对象被作为另一个类的类属性时所有关于这个属性的访问、赋值、删除都会转发给描述符的方法。参数解释一下instance访问属性的那个实例。如果通过类访问这个值是Noneowner描述符所在的类。举一个最直观的例子。我们写一个描述符把访问行为打印出来class LoggerDescriptor: def __get__(self, instance, owner): print(fget: instance{instance}, owner{owner}) return 42 def __set__(self, instance, value): print(fset: instance{instance}, value{value}) class Demo: attr LoggerDescriptor() d Demo() d.attr # get: instance__main__.Demo object at ..., ownerclass __main__.Demo d.attr 100 # set: instance__main__.Demo object at ..., value100d.attr和d.attr 100分别被__get__和__set__截获。本质上描述符把普通属性的读写重定向成了方法的调用。4.2 数据描述符与非数据描述符的优先级描述符分两类这是新手最容易忽略的地方数据描述符实现了__set__和/或__delete__非数据描述符只实现了__get__。两者的优先级完全不同。结合第一节的查找链查找目标优先级数据描述符最高先于实例__dict__实例__dict__第二非数据描述符第三也就是说如果类属性是数据描述符那么即使实例 dict 里有同名键访问时也走描述符的__get__。property是数据描述符所以实例没办法用self._celsius绕过 property 逻辑。而函数是非数据描述符实例 dict 里一旦有同名属性函数就被遮住了。这个遮住特性不是 bug反而是很多高级技巧的根基。下一节我们用两个手写小工具把这两类描述符都用透。4.3 手写一个类型校验描述符先写一个数据描述符用来做属性类型校验。这是Django模型字段、SQLAlchemy列声明的基础思路之一。class Typed: def __init__(self, name, expected_type): self.name name self.expected_type expected_type def __get__(self, instance, owner): if instance is None: return self return instance.__dict__[self.name] def __set__(self, instance, value): if not isinstance(value, self.expected_type): raise TypeError(f{self.name} 期望是 {self.expected_type.__name__}实际是 {type(value).__name__}) instance.__dict__[self.name] value使用方法class Person: name Typed(name, str) age Typed(age, int) def __init__(self, name, age): self.name name self.age age p Person(Alice, 30) print(p.name) # Alice p.age 18 # TypeError: age 期望是 int实际是 str这里有两个极其重要的实操细节第一为什么把数据存到instance.__dict__[self.name]而不是直接setattr(instance, self.name, value)因为后者会再次触发__set__形成无限递归。存到__dict__等于绕过描述符直接写入实例命名空间。所有手写描述符的人早晚会遇到这个 RecursionError提前避坑。第二为什么描述符要接收name参数因为描述符对象自身不知道它被绑定在类的哪个属性名下。你在class Person里写name Typed(name, str)手动传入的字符串必须和属性名一致否则数据存储键就会错乱。这是描述符设计里最原始但最稳定的写法。后面第五节讲元类时我们会探讨自动化这个过程的方案。4.4 手写 cached_propertycached_property是非数据描述符的经典应用。需求是某个属性计算昂贵希望第一次访问时计算并缓存之后直接取缓存。Python 3.8 起标准库提供了functools.cached_property但我们手写一个能把原理看得更清楚class cached_property: def __init__(self, func): self.func func self.name func.__name__ def __get__(self, instance, owner): if instance is None: return self value self.func(instance) instance.__dict__[self.name] value return value用法class DataLoader: def __init__(self, url): self.url url cached_property def data(self): print(正在加载大量数据...) return {mock: data} loader DataLoader(https://example.com/data) print(loader.data) # 第一次访问打印正在加载大量数据... print(loader.data) # 第二次访问直接从实例 __dict__ 返回为什么它能缓存因为cached_property只实现了__get__是非数据描述符。第一次访问时实例__dict__里没有data键查找链走到的描述符的__get__计算出结果后写进实例 dict。第二次访问查找链先找到了实例 dict 里的data优先级高于非数据描述符直接返回缓存值__get__不再触发。亲手实现一遍你对非数据描述符优先级低于实例 dict这句抽象的话就会有肌肉记忆。4.5 真实框架里描述符长什么样很多人觉得描述符是花活但真实框架里它无处不在。Django 的模型字段是描述符思路的典型。你定义一个name models.CharField(max_length100)CharField实例挂在类上访问instance.name时字段描述符负责从底层存储中取数据、反序列化、返回 Python 对象赋值时再序列化、校验、标记脏数据。你在 ORM 层写业务代码基本不会直接碰到描述符但每次赋值和读取都经过它。functools.cached_property、classmethod、staticmethod、property这些内置工具统一都可以看作描述符协议的标准实现。理解了描述符你再看那些库里面调用__get__是什么意思的源码疑问就会豁然开朗。5. 类装饰器与元类在类创建时动手脚属性机制讲完了下一步是类的创建过程。Python 里类本身也是对象所以也能被装饰、被定制。类装饰器和元类是在类创建时动手脚的两种手段前者在类创建后加工后者在类创建过程中拦截。这一章用一个迷你 ORM 字段声明系统把两者串起来。5.1 类装饰器创建之后的统一加工类装饰器就是接收一个类、返回一个类的函数。比如给所有类统一加一个清晰的__repr__def add_repr(cls): def __repr__(self): fields , .join(f{k}{v!r} for k, v in self.__dict__.items()) return f{type(self).__name__} {fields} cls.__repr__ __repr__ return cls add_repr class User: def __init__(self, name, age): self.name name self.age age u User(Alice, 18) print(u) # User age18, nameAlice类装饰器适合批量、统一地修改类。比如给一组数据类加序列化方法、注入公共字段、注册到工厂字典。它比在多个类里重复复制粘贴方法清爽得多。还有一个常见场景把类注册到某个 registry。比方说你写一个插件系统所有被register_plugin装饰的类都会自动进入插件列表。类装饰器在这里非常顺手。5.2 元类真正拦截类的诞生类装饰器是在类创建完成后才生效元类是直接在type生成类的过程中插手。元类本质上是用来创建类的类默认的元类是type。定义元类的标准模板class Meta(type): def __new__(mcs, name, bases, namespace): print(f正在创建类: {name}) cls super().__new__(mcs, name, bases, namespace) return cls class Demo(metaclassMeta): pass # 输出: 正在创建类: DemoMeta.__new__在类对象生成前被调用。参数含义是mcs元类自身name要创建的类名bases基类元组namespace类体命名空间的字典里面装着类定义时的所有属性和方法。注意Python 3 里通过metaclassMeta指定元类和 Python 2 的__metaclass__属性完全不同。元类能做的最经典的事情就是在 namespace 还没变成类之前修改它。这给了你一个类定义阶段的钩子。5.3 一个迷你字段声明系统描述符元类现在把第四节写的Typed描述符和元类结合起来做一个比手写字段更舒服的声明式字段系统。目标在类里写类型注解元类自动把注解字段替换成Typed描述符从而自动获得类型校验能力不需要每写一个字段都手动写x Typed(x, int)。class ModelMeta(type): def __new__(mcs, name, bases, namespace): annotations namespace.get(__annotations__, {}) for field_name, field_type in annotations.items(): namespace[field_name] Typed(field_name, field_type) return super().__new__(mcs, name, bases, namespace) class BaseModel(metaclassModelMeta): pass class Person(BaseModel): name: str age: int p Person() p.name Alice print(p.name) # Alice p.age 18 # TypeError: age 期望是 int实际是 str用户只需要写name: str元类在类创建时扫描注解把name和age替换成Typed(name, str)和Typed(age, int)。这只是个几十行的迷你系统但它已经具备了框架级代码的雏形Django、SQLAlchemy、Pydantic 这类库本质都在做类似的元类加描述符工作只不过复杂度和边界处理远超这个例子。元类使用经验我的态度非常明确能不用就不用能用类装饰器解决的绝不升级到元类。原因很简单元类会参与 MRO 和类的创建多个元类冲突时调试成本极高。而且元类会让新手读代码时一脸懵。真正需要元类的信号是你必须修改类创建过程本身而类装饰器做不到比如需要根据基类的组合关系动态决定类体内容。掌握它不是为了日常炫技而是为了读框架源码时不掉队。6. 抽象基类与协议让鸭子类型更可控最后一章聊一个偏向设计层面的内容抽象基类ABC与协议。Python 是动态语言讲究鸭子类型不强制类型约束但在构建大型项目或框架接口时需要给继承体系提供更明确的结构规范。抽象基类就是标准库给出的答案。6.1 抽象基类与 abstractmethod抽象基类通过abc.ABC和abstractmethod定义类中包含抽象方法子类必须实现所有抽象方法否则不能被实例化。from abc import ABC, abstractmethod class Shape(ABC): abstractmethod def area(self) - float: pass class Circle(Shape): def __init__(self, radius): self.radius radius def area(self) - float: return 3.14159 * self.radius ** 2 class Incomplete(Shape): pass s Shape() # TypeError: Cant instantiate abstract class Shape i Incomplete() # TypeError: Cant instantiate abstract class Incomplete这里的约束是硬的抽象方法没实现实例化直接失败。这给团队协作和框架接口提供了编译期那种逼你实现的感觉虽然不是编译期但错误发生得很早而不是等到调用缺失方法时才崩。抽象基类不只是接口文档它还能写公共逻辑。比如Shape里可以定义一个scale方法内部调用抽象方法area所有子类免费获得这个能力。6.2 注册式抽象基类与鸭子类型抽象基类还有一种更贴合 Python 风格的用法不强制子类继承而是通过register官方承认这个类符合该抽象基类的要求。这在鸭子类型哲学下特别重要。class Rectangle: def __init__(self, width, height): self.width width self.height height def area(self) - float: return self.width * self.height Shape.register(Rectangle) print(isinstance(Rectangle(3, 4), Shape)) # TrueRectangle并没有继承Shape但在类型检查时它是 Shape 的子类。这被称为虚拟子类。register的语义是我保证这个类的实例满足 Shape 的接口约定。它不像继承那样获得代码复用但让isinstance和issubclass的判断能够识别结构符合的对象。更灵活的是__subclasshook__它可以按结构判定子类而不需要显式注册。标准库的collections.abc大量使用了这种机制只要一个类实现了__len__就算你从没继承过Sizedisinstance(obj, Sized)依然返回 True。6.3 collections.abc你无感使用多年的抽象基类collections.abc是 Python 最重要的抽象基类集合你可能没用过它但每天都间接依赖它的判定逻辑。比如isinstance([1, 2, 3], Iterable)返回 True是因为list被注册成了Iterable的虚拟子类。Mapping、Sequence、MutableSet这些类型划分定义了 Python 容器协议的标准。写代码时我建议用这些抽象基类做结构性检查而不是type(x) list这种硬编码判断。比如函数参数是一个可迭代对象那就检查isinstance(data, Iterable)这样生成器、列表、集合、Pandas 的 Series、DataFrame 都能合法传入而不是把类型锁死在 list 上。需要给第三方类补充虚拟子类关系时也可以直接注册比如import collections.abc collections.abc.Mapping.register(MyCustomMapping)这样你的自定义映射类型就能被标准库和第三方库的类型判断正确识别这是接入生态的优雅方式。抽象基类和鸭子类型不是对立的。鸭子类型是 Python 的基础哲学抽象基类是在此之上提供的软性契约硬约束给框架开发者和大型团队软注册给需要兼容生态的库作者。普通业务代码里如果你不需要定义统一接口、没有多态扩展的规划那就少用 ABC直接用鸭子类型加文档约定。又简单又灵活这才是 Python 的日常。最后聊一点个人体会。这一篇讲的属性查找链、描述符、元类、AB C看起来一环扣一环但实际学习和使用时不需要从一开始就全部掌握。我自己是先用明白 property后来在 Django 源码里反复看到描述符才真正吃透它元类则是某次为了给团队写一个轻量 ORM 才强制自己去用。读框架代码遇到不懂的魔法时回头再想想这一篇的属性查找顺序数据描述符优先于实例 dict函数是非数据描述符继承链上的东西最后兜底。把这条链记在脑子里大多数魔法都能拆成一眼就能看穿的流程。