【问题标题】:Why does the `is` operator behave differently in a script vs the REPL?为什么 `is` 运算符在脚本和 REPL 中的行为不同?
【发布时间】:2019-03-25 23:00:14
【问题描述】:

在python中,两个代码有不同的结果:

a = 300
b = 300
print (a==b)
print (a is b)      ## print True
print ("id(a) = %d, id(b) = %d"%(id(a), id(b))) ## They have same address

但在shell模式下(交互模式):

>>> a = 300
>>> b = 300
>>> a is b
False
>>> id(a)
4501364368
>>> id(b)
4501362224

"is" 运算符有不同的结果。

【问题讨论】:

  • @Aran-Fey:以这种方式比较什么类型的对象并不那么重要,但在这种特殊情况下,这是因为编译 .py 源文件的实体注意到 300 == 300 所以只创建了一个 300 实例,而读取 >>> 行的解释器没有注意到 300 == 300 所以创建了两个单独的 300 实例。
  • 不过,is 用于对象标识。只有在你想要的时候才使用它。
  • @Chris 我认为这也不能真正回答问题。就像 torek 所说,这个问题是关于在 REPL 中运行相同代码与作为脚本运行相同代码之间的区别。
  • 正如@Chris 所说。换句话说,具有相同值的两个不可变对象的身份是偶然的,并且不能保证/要求。为什么它一次匹配而一次不匹配因此无关紧要。
  • 伙计们,这些答案都没有真正回答这个问题。 :-(

标签: python cpython


【解决方案1】:

当您在.py 脚本中运行代码时,整个文件在执行它之前compiled 放入代码对象中。在这种情况下,CPython 能够进行某些优化——比如为整数 300 重用同一个实例。

您也可以在 REPL 中重现这一点,方法是在更类似于执行脚本的上下文中执行代码:

>>> source = """\ 
... a = 300 
... b = 300 
... print (a==b) 
... print (a is b)## print True 
... print ("id(a) = %d, id(b) = %d"%(id(a), id(b))) ## They have same address 
... """
>>> code_obj = compile(source, filename="myscript.py", mode="exec")
>>> exec(code_obj) 
True
True
id(a) = 140736953597776, id(b) = 140736953597776

其中一些优化非常激进。您可以修改脚本行b = 300 将其更改为b = 150 + 150,CPython 仍会将b“折叠”成相同的常量。如果您对此类实现细节感兴趣,请查看 peephole.c 和 Ctrl+F 以获取 PyCode_Optimize 以及有关“consts 表”的任何信息。

相反,当您直接在 REPL 中逐行运行代码时,它会在不同的上下文中执行。每一行都以“单”模式编译,这种优化不可用。

>>> scope = {} 
>>> lines = source.splitlines()
>>> for line in lines: 
...     code_obj = compile(line, filename="<I'm in the REPL, yo!>", mode="single")
...     exec(code_obj, scope) 
...
True
False
id(a) = 140737087176016, id(b) = 140737087176080
>>> scope['a'], scope['b']
(300, 300)
>>> id(scope['a']), id(scope['b'])
(140737087176016, 140737087176080)

【讨论】:

  • b=150+150在Python3.6中没有优化,但有更高版本。
【解决方案2】:

关于 CPython 及其行为,实际上有两件事需要了解。 首先,在[-5, 256] 范围内的小整数在内部被实习。 因此,任何落在该范围内的值都将共享相同的 id,即使在 REPL 中也是如此:

>>> a = 100
>>> b = 100
>>> a is b
True

由于 300 > 256,它没有被拘留:

>>> a = 300
>>> b = 300
>>> a is b
False

其次,在脚本中,文字被放入 编译的代码。 Python 足够聪明地意识到这一点,因为 ab 参考文字 300 并且 300 是一个不可变的对象,它可以只是 继续并引用相同的常量位置。如果你调整你的脚本 一点,写成:

def foo():
    a = 300
    b = 300
    print(a==b)
    print(a is b)
    print("id(a) = %d, id(b) = %d" % (id(a), id(b)))


import dis
dis.disassemble(foo.__code__)

输出的开头部分如下所示:

2           0 LOAD_CONST               1 (300)
            2 STORE_FAST               0 (a)

3           4 LOAD_CONST               1 (300)
            6 STORE_FAST               1 (b)

...

如您所见,CPython 使用相同的常量槽加载ab。 这意味着ab 现在指的是同一个对象(因为它们 引用相同的插槽),这就是为什么 a is b 在脚本中是 True 但 不在 REPL。

如果您将语句包装在一个函数中,您也可以在 REPL 中看到这种行为:

>>> import dis
>>> def foo():
...   a = 300
...   b = 300
...   print(a==b)
...   print(a is b)
...   print("id(a) = %d, id(b) = %d" % (id(a), id(b)))
...
>>> foo()
True
True
id(a) = 4369383056, id(b) = 4369383056
>>> dis.disassemble(foo.__code__)
  2           0 LOAD_CONST               1 (300)
              2 STORE_FAST               0 (a)

  3           4 LOAD_CONST               1 (300)
              6 STORE_FAST               1 (b)
# snipped...

底线:虽然 CPython 有时会进行这些优化,但您不应该真正指望它——它实际上是一个实现细节,并且随着时间的推移它们已经改变(CPython 过去只对不超过100,例如)。如果您要比较数字,请使用==。 :-)

【讨论】:

  • 这个答案还有很多不足之处:通过“调整脚本”,您将代码放入函数范围(本地变量)而不是模块范围(全局变量),其中 - 在执行和名称解析的条款 - 现在是完全不同的范围界定情况。我认为这在某种程度上使反汇编无效。是的,它碰巧在模块代码上使用相同的窥视孔优化器,就像在函数体上使用它一样,但当然不必如此。并且答案也没有真正解释为什么没有直接在 REPL 上进行相同的优化。
  • @wim 如果您认为它不符合标准,我当然会删除答案。我个人不认为调整是负面的,但我听到你的声音 - 它不完全相同。但我认为所有这些都与 Python 今天所做的事情息息相关,并不能保证 Python 将来会做什么。这是一个公平的批评——我没有明确说明为什么 REPL 中的逐行不同。
  • 哦,我认为您不应该删除它,只需更新它!我确实认为反汇编演示是有用的内容。但是,它应该 dis 模块范围代码,而不是函数范围代码 - 最新版本的 dis 允许您直接传入源字符串,因此没有必要使用函数对象的 __code__ 属性。
  • @wim 这对你来说似乎不太公平——我认为你已经完成了这方面的工作,你的答案应该是公认的答案(尽管我认为添加小实习答案的整数很好,以防人们尝试得到他们不期望的结果)。
猜你喜欢
  • 2019-12-11
  • 2012-01-10
  • 1970-01-01
  • 2017-02-10
  • 2010-12-29
  • 1970-01-01
  • 1970-01-01
  • 2017-03-23
  • 2015-11-18
相关资源
最近更新 更多