`is` 运算符对非缓存整数的行为异常 [英] The `is` operator behaves unexpectedly with non-cached integers

问题描述

在玩 Python 解释器时，我偶然发现了这个关于 is 运算符的冲突案例:

如果在函数中进行求值，则返回True，如果在函数外进行，则返回False.

<预><代码>>>>定义函数():... a = 1000... b = 1000...返回 a 是 b...>>>一 = 1000>>>b = 1000>>>a 是 b，func()(假，真)

由于 is 运算符为所涉及的对象计算 id()，这意味着 a 和 b 在函数 func 内部声明时指向相同的 int 实例，但相反，它们在函数外部时指向不同的对象.

为什么会这样?

<小时>

<sup>注意:我知道身份(is)和相等(==)操作之间的区别，如理解 Python 的is"操作员.此外，我还知道 python 正在为 [-5, 256] 范围内的整数执行缓存，如 是"运算符对整数的行为出乎意料.

这里不是这种情况，因为数字超出了该范围并且我确实想要评估身份和不平等.</sup>

解决方案

tl;dr:

正如参考手册所述:

<块引用>

块是作为一个单元执行的一段 Python 程序文本.以下是块:模块、函数体和类定义.交互输入的每个命令都是一个块.

这就是为什么，在函数的情况下，您有一个单个代码块，其中包含一个单个对象用于数字文字1000，所以 id(a) == id(b) 将产生 True.

在第二种情况下，您有两个不同的代码对象，每个对象都有自己不同的对象用于文字 1000 所以 id(a) != id(b).

请注意，此行为不会仅通过 int 文字表现出来，您将获得类似的结果，例如，float 文字(请参阅 此处).

当然，比较对象(显式的 is None 测试除外)应该始终使用相等运算符 == 和 not <代码>是.

_{这里所说的一切都适用于最流行的 Python 实现，CPython.其他实现可能会有所不同，因此在使用它们时不应做出任何假设.}

---

更长的答案:

为了获得更清晰的视图并另外验证这种看似奇怪的行为，我们可以直接查看code 对象，用于使用 dis 模块.

对于函数func:

除了所有其他属性外，函数对象还有一个 __code__ 属性，允许您查看该函数的编译字节码.使用 dis.code_info 我们可以获得给定函数的代码对象中所有存储属性的漂亮视图:

<预><代码>>>>打印(dis.code_info(函数))名称:函数文件名:<stdin>参数计数:0仅限 Kw 的参数:0本地人数:2堆栈大小:2标志:优化、新本地、NOFREE常数:0:无1:1000变量名:0:一个1:乙

我们只对函数 func 的 Constants 条目感兴趣.在其中，我们可以看到我们有两个值，None(始终存在)和 1000.我们只有一个 single int 实例来表示常量 1000.这是在调用函数时将分配给 a 和 b 的值.

通过 func.__code__.co_consts[1] 很容易访问这个值，因此，在函数中查看我们的 a is b 评估的另一种方法是这样的:

<预><代码>>>>id(func.__code__.co_consts[1]) == id(func.__code__.co_consts[1])

当然，这将评估为 True，因为我们指的是同一个对象.

对于每个交互式命令:

如前所述，每个交互式命令都被解释为单个代码块:独立解析、编译和评估.

我们可以通过 compile 获取每个命令的代码对象 内置:

<预><代码>>>>com1 = compile("a=1000", 文件名="", mode="single")>>>com2 = compile("b=1000", 文件名="", mode="single")

对于每个赋值语句，我们将得到一个类似的代码对象，如下所示:

<预><代码>>>>打印(dis.code_info(com1))名称:<模块>文档名称:参数计数:0仅限 Kw 的参数:0本地人数:0堆栈大小:1标志:NOFREE常数:0:10001:无姓名:0:一个

com2 的相同命令看起来相同但有根本区别:每个代码对象 com1 和 com2 具有表示文字 1000 的不同 int 实例.这就是为什么，在这种情况下，当我们通过 co_consts 参数做 a is b 时，我们实际上得到:

<预><代码>>>>id(com1.co_consts[0]) == id(com2.co_consts[0])错误的

这与我们实际得到的一致.

不同的代码对象，不同的内容.

---

注意:我有点好奇源代码中究竟是如何发生这种情况的，经过深入研究后，我相信我终于找到了.

在编译阶段 co_consts 属性由一个字典对象表示.在 compile.c 中，我们实际上可以看到初始化:

/* 为简洁起见的片段 */u->u_lineno = 0;u->u_col_offset = 0;u->u_lineno_set = 0;u->u_consts = PyDict_New();/* 为简洁起见的片段 */

在编译期间，会检查已经存在的常量.请参阅下面@Raymond Hettinger 的回答，了解更多信息.

---

注意事项:

• 链式语句将评估为 True

  的身份检查

  现在应该更清楚为什么下面的计算结果为 True:

   >>>一 = 1000;b = 1000；>>>a 是 b

  在这种情况下，通过将两个赋值命令链接在一起，我们告诉解释器将这些一起编译.与函数对象的情况一样，将只为文字 1000 创建一个对象，从而在评估时产生 True 值.

• 在模块级别执行再次产生 True:

  如前所述，参考手册指出:

  <块引用>

  ... 以下是块:一个模块 ...

  所以同样的前提适用:我们将有一个代码对象(用于模块)，因此，每个不同的文字都会存储单个值.

• 同样的不适用于可变对象:

意思是除非我们显式地初始化为同一个可变对象(例如用a = b = [])，对象的身份永远不会相等，例如:

 a = [];b = []a is b # 总是评估为 False

同样，在文档，这是指定的:

<块引用>

a = 1 之后；b = 1，a 和 b 可能引用也可能不引用值为 1 的同一个对象，这取决于实现，但在 c = [] 之后；d = []，c 和 d 保证引用两个不同的、唯一的、新创建的空列表.

When playing around with the Python interpreter, I stumbled upon this conflicting case regarding the is operator:

If the evaluation takes place in the function it returns True, if it is done outside it returns False.

>>> def func():
...     a = 1000
...     b = 1000
...     return a is b
...
>>> a = 1000
>>> b = 1000
>>> a is b, func()
(False, True)

Since the is operator evaluates the id()'s for the objects involved, this means that a and b point to the same int instance when declared inside of function func but, on the contrary, they point to a different object when outside of it.

Why is this so?

---

<sup>Note: I am aware of the difference between identity (is) and equality (==) operations as described in Understanding Python's "is" operator. In addition, I'm also aware about the caching that is being performed by python for the integers in range [-5, 256] as described in "is" operator behaves unexpectedly with integers.

This isn't the case here since the numbers are outside that range and I do want to evaluate identity and not equality.</sup>

解决方案

tl;dr:

As the reference manual states:

A block is a piece of Python program text that is executed as a unit. The following are blocks: a module, a function body, and a class definition. Each command typed interactively is a block.

This is why, in the case of a function, you have a single code block which contains a single object for the numeric literal 1000, so id(a) == id(b) will yield True.

In the second case, you have two distinct code objects each with their own different object for the literal 1000 so id(a) != id(b).

Take note that this behavior doesn't manifest with int literals only, you'll get similar results with, for example, float literals (see here).

Of course, comparing objects (except for explicit is None tests ) should always be done with the equality operator == and not is.

_{Everything stated here applies to the most popular implementation of Python, CPython. Other implementations might differ so no assumptions should be made when using them.}

---

Longer Answer:

To get a little clearer view and additionally verify this seemingly odd behaviour we can look directly in the code objects for each of these cases using the dis module.

For the function func:

Along with all other attributes, function objects also have a __code__ attribute that allows you to peek into the compiled bytecode for that function. Using dis.code_info we can get a nice pretty view of all stored attributes in a code object for a given function:

>>> print(dis.code_info(func))
Name:              func
Filename:          <stdin>
Argument count:    0
Kw-only arguments: 0
Number of locals:  2
Stack size:        2
Flags:             OPTIMIZED, NEWLOCALS, NOFREE
Constants:
   0: None
   1: 1000
Variable names:
   0: a
   1: b

We're only interested in the Constants entry for function func. In it, we can see that we have two values, None (always present) and 1000. We only have a single int instance that represents the constant 1000. This is the value that a and b are going to be assigned to when the function is invoked.

Accessing this value is easy via func.__code__.co_consts[1] and so, another way to view our a is b evaluation in the function would be like so:

>>> id(func.__code__.co_consts[1]) == id(func.__code__.co_consts[1]) 

Which, of course, will evaluate to True because we're referring to the same object.

For each interactive command:

As noted previously, each interactive command is interpreted as a single code block: parsed, compiled and evaluated independently.

We can get the code objects for each command via the compile built-in:

>>> com1 = compile("a=1000", filename="", mode="single")
>>> com2 = compile("b=1000", filename="", mode="single")

For each assignment statement, we will get a similar looking code object which looks like the following:

>>> print(dis.code_info(com1))
Name:              <module>
Filename:          
Argument count:    0
Kw-only arguments: 0
Number of locals:  0
Stack size:        1
Flags:             NOFREE
Constants:
   0: 1000
   1: None
Names:
   0: a

The same command for com2 looks the same but has a fundamental difference: each of the code objects com1 and com2 have different int instances representing the literal 1000. This is why, in this case, when we do a is b via the co_consts argument, we actually get:

>>> id(com1.co_consts[0]) == id(com2.co_consts[0])
False

Which agrees with what we actually got.

Different code objects, different contents.

---

Note: I was somewhat curious as to how exactly this happens in the source code and after digging through it I believe I finally found it.

During compilations phase the co_consts attribute is represented by a dictionary object. In compile.c we can actually see the initialization:

/* snippet for brevity */

u->u_lineno = 0;
u->u_col_offset = 0;
u->u_lineno_set = 0;
u->u_consts = PyDict_New();  

/* snippet for brevity */

During compilation this is checked for already existing constants. See @Raymond Hettinger's answer below for a bit more on this.

---

Caveats:

• Chained statements will evaluate to an identity check of True

  It should be more clear now why exactly the following evaluates to True:

   >>> a = 1000; b = 1000;
   >>> a is b
  

  In this case, by chaining the two assignment commands together we tell the interpreter to compile these together. As in the case for the function object, only one object for the literal 1000 will be created resulting in a True value when evaluated.

• Execution on a module level yields True again:

  As previously mentioned, the reference manual states that:

  ... The following are blocks: a module ...

  So the same premise applies: we will have a single code object (for the module) and so, as a result, single values stored for each different literal.

• The same doesn't apply for mutable objects:

Meaning that unless we explicitly initialize to the same mutable object (for example with a = b = []), the identity of the objects will never be equal, for example:

    a = []; b = []
    a is b  # always evaluates to False

Again, in the documentation, this is specified:

after a = 1; b = 1, a and b may or may not refer to the same object with the value one, depending on the implementation, but after c = []; d = [], c and d are guaranteed to refer to two different, unique, newly created empty lists.

这篇关于`is` 运算符对非缓存整数的行为异常的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！