python intern 机制学习和思考

本人Python能力有限，介意请直接看参考文档，所以我把参考文档（筛选后的）写在了前面。本文主要是根据自己在学习intern机制时参看一些文档和相关Python的理解总结而成，因为网上不同的文档内容参差不齐，避免大家走弯路。

参考文档：
1、https://medium.com/techtofreedom/string-interning-in-python-a-hidden-gem-that-makes-your-code-faster-9be71c7a5f3e

2、https://medium.com/@bdov_/https-medium-com-bdov-python-objects-part-iii-string-interning-625d3c7319de

3、https://segmentfault.com/a/1190000017217606

4、https://blog.csdn.net/qq_39478403/article/details/106201512

5、https://stackabuse.com/guide-to-string-interning-in-python/

6、https://zhuanlan.zhihu.com/p/351244769

7、https://www.code05.com/question/detail/55643933.html

intern,直接翻译是驻留等意思。在Python中比较为大家所熟知的是字符串驻留机制，也就是string interning.其实一般常见的小整数池也可以看成Interger interning.

1、小整数池/整数驻留

为避免因创建相同的值而频繁申请和回收内存空间带来的效率问题，Python 解释器会在启动时创建一个范围为 [-5, 256] 的 小整数池，该范围内预定义的“小”整数对象将在全局解释器范围内被重复使用，而不会被垃圾回收机制回收。

x = 256
y = 256
print(x is y)

x = -5
y = -5
print(x is y)

x = 257
y = 257
print(x is y)
----------------
True
True
False

2、字符串驻留/String Intern

怎么理解字符串驻留？直白的意思就是，有一部分字符串在内存中只会存一份，其他的相同值的字符串都是对它的引用。

怎么理解这种技术的产生？
众所周知，Python 字符串是不可变对象。当一个字符串被声明生成时，就无法在修改或者更新这个字符串了，那么在编码过程中经常会遇到多个变量赋予相同字符串值的情况，难道每次赋予一次都创建一个相同的字符串在内存中？显然不合适，于是就有了字符串驻留机制。

这样做有两个好处：

• 节省内存空间；
• 降低比较字符串的时间复杂度。

这两点都比较好理解，当相同的值的字符串都只有一份时，明显会降低空间。而在比较两个字符串是否相等的时候，如果两个字符串变量指向的是同一个内存地址，明显就是相等的。

当然，对应的就有缺点：

• 要实现字符串驻留，就得长时间保存这些字符串在内存中，因此会有一个字符串驻留池来保存这些字符串。

因此，为了降低字符串驻留的成本和开销，Python并不是把所有的字符串都自动驻留在内存里了。

2.1、自动驻留

自动驻留，就是字面意思，解释器自动驻留这些字符串在内存中。

哪些字符串会被自动驻留在内存着呢？

自动驻留的场景：

• 场景1：字符串必须是编译时就确定的常量，不能是运行时才计算出来的。常见的表达式、函数等都是运行时计算。
• 场景2：在Python 3.7为止，长度超过20个字符的字符串不会被驻留，之后得Python版本，通过语法解释器优化，可以支持最长4096字符长度的字符串驻留。这一点也是会引起困惑的地方，很多博客要么直接写的超过20个字符，有的要么写没有长度限制。
• 场景3：所有的ascll码字符、数字和下划线组成的字符串。
• 场景4：除了显式的自己命名的变量外，函数名、类名、变量、参数名等都会被驻留。(其实这些变量名的规范都符合场景3）。
• 场景5：所有字典的键，不仅包含显式定义的字典，还有类、模块还有实例变量属性等相关的字典。
• 场景6：特例：所有的空字符串。

其实场景(条件)很多，但是我觉得记住了解主要的几点就行，参考下面判断是否驻留的逻辑流程来理解我觉得不错：

了解这个流程后，我们再来用几个实例来强化理解一下，看看和认知是否有差异。

# 场景1、运行时和编译时字符串
x = "a"*21
y = "a"*21
print(x is y)
# True

x = "Holberton" + "Holberton" + "Holberton"
y = "Holberton" + "Holberton" + "Holberton"
print(x is y)
# True

x = "a"*5
y = "".join("aaaaa")
print(x is y)
# False

# 场景2、4096的长度约束是否正确
x = "a"*4096
y = "a"*4096
print(x is y)
# True

x = "a"*4097
y = "a"*4097
print(x is y)
# False

# 其他
x = "abc!"
y = "abc!"
print(x is y)
# False

2.2、手动驻留

可以通过显式使用intern函数来驻留字符串。

import sys
x = sys.intern("abc!")
y = sys.intern("abc!")
print( x is y)
# True

3、几点例子的思考

3.1、常量折叠（Constant Folding）和字符串驻留

在上文自动触发字符串驻留的场景2中，对驻留的字符串长度扩展到4096，是因为解释器在编译的时候进行了AST optimizer （抽象语法树分析优化）。在这个优化中使用了一种常量折叠的技术：在编译期间，编译器会设法识别出常量表达式，对其进行求值，然后用求值的结果来替换表达式，从而使得运行时更精简。

在例子中代码即’a’*4096被编译时，interning发生。 通常，在编译时，这将导致以下字节码：

 0 LOAD_CONST               1 ('a')
 2 LOAD_CONST               2 (4096)
 4 BINARY_MULTIPLY

但是，因为两者都是常量，所以在编译时可以通过peephole-optimizer为BINARY_MULTIPLY执行常量折叠，这发生在fold_binop:

static int
fold_binop(expr_ty node, PyArena *arena, int optimize)
{
    ...
    PyObject *newval;

    switch (node->v.BinOp.op) {
    ...
    case Mult:
        newval = safe_multiply(lv, rv);
        break;
    case Div:
     ...
    }

    return make_const(node, newval, arena);
}

如果可以计算safe_multiply，则结果被添加到make_const中的常量列表中，如果safe_multiply返回NULL，则不会发生任何事情-无法执行优化。
safe_multiply仅在生成的字符串不大于4096个字符时执行：

#define MAX_STR_SIZE          4096  /* characters */

static PyObject *
safe_multiply(PyObject *v, PyObject *w)
{
    ...
    else if (PyLong_Check(v) && (PyUnicode_Check(w) || PyBytes_Check(w))) {
        Py_ssize_t size = PyUnicode_Check(w) ? PyUnicode_GET_LENGTH(w) :
                                               PyBytes_GET_SIZE(w);
        if (size) {
            long n = PyLong_AsLong(v);
            if (n < 0 || n > MAX_STR_SIZE / size) {  //HERE IS THE CHECK!
                return NULL;
            }
        }
    }
    ...
}

因此’a’*4096成为interned，‘a’*4097不是，对于第一种情况，优化的字节代码现在是：

 0 LOAD_CONST               3 ('aaaaaaaaa...aaaaaaaaaaa')

整个优化代码可以查看CPython的源码中的ast_opt.c文件。
https://github.com/python/cpython/blob/3.7/Python/ast_opt.c

Python3.7之前的20的限制参看https://github.com/python/cpython/blob/0f21fe6155227d11dc02bd3ef3b061de4ecea445/Python/peephole.c。

3.2、查看下面代码和返回结果

a = 'asd!'
b = 'asd!'
print(a is b)
# False

def foo():
    a = 'asd!'
    b = 'asd!'
    print(a is b)
foo()
# True

根据上面代码的输出，是否会觉得intern机制是不是有问题了？这里面其实涉及到一个问题：python交互式逐行解释和整体解释（脚本或者函数、类等）是否有啥不一样？

这个和CPython解释器中设定的编译单元相关。

整体解释中的函数、模块都会算一个编译单元，每个函数独编译，得到的结果是一个PyFunctionObject对象，其中带有字节码、常量池等各种信息。

dis(foo)
7           0 LOAD_CONST               1 ('asd!')
              2 STORE_FAST               0 (a)

  8           4 LOAD_CONST               1 ('asd!')
              6 STORE_FAST               1 (b)

  9           8 LOAD_GLOBAL              0 (print)
             10 LOAD_FAST                0 (a)
             12 LOAD_FAST                1 (b)
             14 COMPARE_OP               8 (is)
             16 CALL_FUNCTION            1
             18 POP_TOP
             20 LOAD_CONST               0 (None)
             22 RETURN_VALUE

查看上面foo函数的字节码，会发现变量a和b都是从常量池里获得LOAD_CONST 1。

每个PyFunctionObject有一个独立的常量池；换句话说，每个PyFunctionObject的co_const字段都指向自己专有的一个常量池对象，而里面的常量池项也是自己专有的。在同一个编译单元（PyFunctionObject）里出现的值相同的常量，只会在常量池里出现一份，一定会对应到运行时的同一个对象。所以在foo()的例子里，a和b都从同一个常量池项获取值；

在不同的编译单元里，值相同的常量不一定会对应到运行时的同一个对象，要看具体的类型是否自带了某种interning / caching机制。

而逐行解释实际上每行都是一个编译单元，因此会应用实际的intern机制来判断。

4、总结与思考

intern机制时Python解释器的一个设计的巧思。在学习的过程中，会发现单纯简单的从intern来解释其实很多地方是解释不通的。
例如为啥之前是限定20个字符，现在变成了4096，实际上是AST optimizer在起作用。

很多时候看到的一个结果，可能是多个机制或者优化手段达成的，这也为我们学习Python提高了难度，也是学习的乐趣所在。由于本人C语言能力有限，很多底层的原理和机制都是参考学习。