Python 语法糖探秘：def 与 class 的真实身份

一、语法糖的“含糖量”在哪里

Python 给人的第一印象往往是语法简洁、贴近自然语言，但简洁的背后是一套设计精巧的执行机制。许多看起来理所当然的语法，本质上只是对底层操作的“包装”。理解这些包装，不仅能回答各类原理层面的追问，更能解锁一批常规写法做不到的技巧。本文聚焦两条最值得玩味的语法糖：def 与 class——它们本质上都是赋值语句，只是“赋值之前发生的事”一个比一个复杂。

二、def 的本质：一条赋值语句

2.1 执行流程三步拆解

以最简单的函数定义为例：

def f(a=b):
    print(a)

解释器处理这段代码时，实际发生的事情可以拆成三步：

1. 编译期：函数 f 的代码块被编译成一个 code object（代码对象），作为常量嵌入到外层代码块（比如模块）的字节码中；
2. 运行期：程序执行到 def 这一行时，解释器根据 code object 动态构建出一个 function object（函数对象）；
3. 绑定期：把这个 function object 赋值给名字 f。

也就是说，“定义函数”在执行层面是“先构造对象、再给变量赋名”。f 从头到尾都只是一个普通的变量名，与 x = 1 中的 x 没有本质区别——它可以被重新赋值、被删除、被塞进列表或字典、被当作参数传来传去。函数是“一等公民”，正是这条赋值语义的直接体现。

2.2 为什么需要 function object 这层封装

为什么不直接把 code object 赋给变量？因为 code object 只是一份“静态模板”，它记录字节码指令、常量表、参数个数等编译期即可确定的信息；而一个“可以被调用的函数”还需要携带大量运行时动态信息，这些信息全部挂在 function object 上：

• 参数默认值：默认值表达式在 def 执行的那一刻求值一次，并把结果绑定到函数对象上。这也是“可变默认值陷阱”的根源——若默认值是列表或字典，所有调用将共享同一个对象；
• 闭包信息：若 f 是内层函数并捕获了外层作用域的变量，这些引用会以 cell 对象的形式记录在函数对象的闭包结构中；
• 全局命名空间引用：函数执行时查找全局名字所用的字典，在函数对象创建时确定；
• 名字、限定名、文档字符串等元信息。

一言以蔽之：code object 负责“代码是什么”，function object 负责“这段代码在哪个上下文里跑”。有了这层封装，函数才能作为对象自由传递，闭包、装饰器等特性才有物质基础。

三、class 的本质：一次“伪装成函数”的执行

class 的行为可以由 def 的机制推广理解，但它更复杂也更有意思：class 同样是一条赋值语句，赋值之前执行的是一段“伪函数”。

3.1 类体是一个“伪函数”

解释器运行到 class 语句时，会把类下面的整个代码块当作一个函数体来执行，但这个“函数”与正常函数相比存在几处语法层面的差异：

1. 无输入参数：类体不接受任何形参，不存在参数绑定；
2. 不能显式 return：类体里写 return 会直接触发语法错误；
3. 类体中 def 出的函数不构成闭包：类体作用域不会进入方法的作用域链，这正是“方法内部访问类属性必须通过 self 或类名”的根本原因——类体的局部命名空间对方法不可见。

此外还有一个容易被忽略的细节：类体使用独立的命名空间查找规则，属性名解析走的是类命名空间字典，与普通函数的局部变量机制不同。

3.2 执行完毕后，环境不销毁

普通函数调用结束时，局部变量随调用帧一起销毁。而类体执行结束后，解释器做了一件截然不同的事：不销毁局部环境，而是把“幸存”的局部变量整体转换为类的属性，据此构建出 class object，最后把它赋值给类名。

没错——类名也是一个变量。你可以对它重新赋值、删除、放进容器，甚至在运行时替换。理解了“类定义的瞬间其实是一次构造过程”，很多进阶玩法就顺理成章了。

四、构造期编程：让类体替你干活

4.1 按运行时条件决定方法的形态

既然类体是一段可执行代码，那么 if/else、循环、函数调用都可以出现在其中：

class A:
    i = input()            # 类体中可执行任意语句，发生在定义类的那一刻
    if i == "a":
        def f(self):
            print("user select a")
    else:
        def f(self):
            print("user select b")
    del i                  # 清理临时变量
a = A()
a.f()

这个例子体现了三个要点：

• 类体中的 input() 在“执行到 class 语句”时求值，而不是在实例化时；
• if/else 让同一个方法名 f 根据外部环境绑定到不同实现上，类定义瞬间完成“多选一”；
• del i 是关键一步：i 是类体执行期间的一个“局部变量”，若不删除，它将随命名空间一起成为 A 的属性（俗称“类静态变量”）。del 的作用就是做“构造期清理”，只留下想要的东西。

4.2 批量生成方法

若要为一组不同宽度的字节串分别提供解包方法，逐个手写几乎相同的代码，冗长且易错。利用类体可直接执行循环的特性，可以批量“生产”方法：

import struct
class Pkg:
    for _fmt in "BHIQ":
        exec(
            'unpack_%s = lambda self: struct.unpack("!%s", self.bytes)[0]'
            % (_fmt, _fmt)
        )
    del _fmt
    __str__ = __repr__ = lambda self: repr(self.bytes)

执行到 for 循环时，解释器连续跑四遍循环体，向类命名空间中动态写入 unpack_B、unpack_H、unpack_I、unpack_Q 四个方法；最后 del _fmt 保持类属性整洁。两点补充说明：

• lambda 与 def 造出来的是同一种 function object，只是书写形式不同，这里用 lambda 纯粹是为了让源码字符串足够短；
• 之所以借助 exec 而不是直接在循环里写 lambda，是因为 Python 闭包遵循“晚绑定”：循环变量 _fmt 在所有 lambda 中指向同一个名字，等到真正调用方法时才取值，四个方法拿到的都会是循环结束时的最后一个格式字符。exec 为每个方法生成了各自独立的源码，从根上绕开了这个问题。改用带默认参数的技巧（如 lambda self, f=_fmt: ...）或偏函数工具同样能解决，这是理解闭包绑定机制的经典练习题。

4.3 这类写法的边界

类体中“夹带逻辑”很强大，但可读性是代价：静态分析工具往往无法推断类体中动态产生的属性，阅读者也难以一眼看出类的最终形态。实践建议是：批量、模式化的场景（如按协议字段生成方法）值得用；零散的业务判断尽量收敛到工厂函数或元类中，并配注释说明意图。

五、收尾阶段：从 function 到 method 的转换

类体执行完成后，并非简单地把残余局部变量表原样拷贝成类的属性，而是有一道关键的“类型转换”工序。

5.1 转换发生在类构造的收尾

先做一个观察实验（以早期 Python 2 的行为为例）：

class A:
    def f(self):
        print("f")
    print(f)        # 此时 f 还是一个普通函数（function）
    f(None)         # 可以直接当普通函数调用，self 位置显式传参即可
print(A.f)          # 类构造完成后，A.f 已是"未绑定方法"（unbound method）
A().f()             # 通过实例访问时，self 被自动绑定

类体执行中途，f 就是一个普通的 function；而类体结束、class object 构建完成之后，A.f 已经被转换成了 method。这说明转换不是发生在 def 那一刻，而是发生在“构造类”的收尾阶段。

5.2 staticmethod 与 classmethod 的特殊待遇

如果在类体中用 staticmethod 或 classmethod 修饰某个函数，收尾阶段的处理就会不同：被修饰的对象要么不参与 method 转换，要么按另一种方式包装。换句话说，class 的构造过程必须“认识”这两个修饰器产生的对象，并对它们执行专门的绑定策略——这也是二者存在感如此特殊的底层原因。

进入 Python 3 后，这套机制在形式上进一步简化：函数存入类属性表时保持原样（A.f 就是那个函数本身），“方法视图”改为在属性访问时按描述符协议动态生成——通过实例访问时才临时产生一个绑定了 self 的方法对象；staticmethod 与 classmethod 则作为两种特殊描述符，分别声明“不做实例绑定”与“绑定到类本身”。理解这条演进线，就能把两个版本中“方法”的差异看作同一机制在不同时期的两种实现。

六、顺着这套机制还能推出什么

把“def/class 都是赋值、类体即代码”这两条原理吃透，许多常见问题都会变得直观：

• 类体中的属性表达式只在类构造时求值一次，与函数默认值陷阱同源，共享可变对象时务必小心；
• 嵌套作用域中循环变量的晚绑定行为，是闭包绑定机制的直接推论；
• class 语句在语义上近似于“准备好名字、基类与命名空间字典，再调用元类完成构造”，这也解释了为什么能用 type(name, bases, dict) 三参形式动态建类——class 语句本身可以看作这套调用的语法糖；
• 装饰器之所以能作用于函数和类，正是因为二者都是“构造完成后被赋名的对象”，自然可以在赋名前被装饰器拦截、加工再放回原名下。

七、小结

Python 的“好玩”不在于花哨，而在于规则少而自洽：def 与 class 皆为赋值，类体本身就是可执行代码。掌握这两条底层原理，你写出的就不再只是“能跑的类定义”，而是一个能在构造期完成条件装配、批量生产、属性清理的“微型构建系统”。当然，语法糖终究是糖——用到恰到好处是技巧，处处炫技则是负担。理解机制、克制使用，才是这些“好玩”特性真正的打开方式。