为什么函数（Python）的 __code__ 是可变的

在昨天的上一个问题中，在评论中，我开始知道在 python 中__code__函数的属性是可变的。因此我可以编写如下代码

def foo():
    print "Hello"

def foo2():
    print "Hello 2"

foo()
foo.__code__ = foo2.__code__
foo()

Output

Hello
Hello 2

我尝试谷歌搜索，但要么是因为没有信息（我非常怀疑这一点），要么是关键字（__code__）不容易搜索，我找不到这方面的用例。

“因为 Python 中的大多数东西都是可变的”似乎也不是一个合理的答案，因为函数的其他属性 -__closure__ and __globals__- 明确只读（来自对象/funcobject.c https://github.com/python/cpython/blob/master/Objects/funcobject.c#L236):

static PyMemberDef func_memberlist[] = {
    {"__closure__",   T_OBJECT,     OFF(func_closure),
     RESTRICTED|READONLY},
    {"__doc__",       T_OBJECT,     OFF(func_doc), PY_WRITE_RESTRICTED},
    {"__globals__",   T_OBJECT,     OFF(func_globals),
     RESTRICTED|READONLY},
    {"__module__",    T_OBJECT,     OFF(func_module), PY_WRITE_RESTRICTED},
    {NULL}  /* Sentinel */
};

为什么会__code__是可写的，而其他属性是只读的？

事实是，Python 中的大多数东西are可变的。所以真正的问题是，为什么__closure__ and __globals__ not?

答案乍一看似乎很简单。这两件事都是函数可能需要的变量的容器。代码对象本身并不携带其封闭变量和全局变量；它只知道如何从函数中获取它们。当函数被调用时，它从这两个属性中获取实际值。

但范围本身是可变的，所以这个答案并不令人满意。我们需要解释为什么修改这些东西特别会破坏东西。

For __closure__，我们可以看看它的结构。它不是映射，而是单元元组。它不知道封闭变量的名称。当代码对象查找封闭变量时，它需要知道它在元组中的位置；他们一对一地匹配co_freevars这也是只读的。如果元组的大小错误或根本不是元组，则如果底层 C 代码没有预料到这种情况，则该机制可能会严重崩溃（读取：段错误）。强制 C 代码检查元组的类型和大小是不必要的繁琐工作，可以通过将属性设置为只读来消除。如果您尝试更换__code__具有不同数量的自由变量的东西，你得到一个错误 https://github.com/python/cpython/blob/master/Objects/funcobject.c#L269，所以尺寸总是正确的。

For __globals__，解释不太明显，但我会推测。作用域查找机制期望始终能够访问全局命名空间。事实上，字节码可能是硬编码的 https://docs.python.org/2/library/dis.html#opcode-LOAD_GLOBAL直接进入全局命名空间，如果编译器可以证明没有其他命名空间会有具有特定名称的变量。如果全局命名空间突然None或者其他一些非映射对象，C 代码可能会再次出现严重的错误行为。同样，让代码执行不必要的类型检查会浪费 CPU 周期。

另一种可能性是（通常声明的）函数借个参考 https://docs.python.org/3/c-api/intro.html#reference-count-details到模块的全局命名空间，并使属性可写会导致引用计数混乱。我可以想象这种设计，但我不太确定这是一个好主意，因为可以使用生命周期可能比所属模块短的对象显式构造函数，并且这些对象需要特殊处理。