为什么IPython的行为不同于Python的行为？

如何解决为什么IPython的行为不同于Python的行为？

在Python 3.8.5 shell中，我有：

>>> id([])
140370451791744
>>> id([])
140370451791744
>>> id([])

在运行Python 3.8.5的IPython 7.18.1中，我有：

In [1]: id([])
Out[1]: 139870334633536

In [2]: id([])
Out[2]: 139870334633152

这引出了以下问题：为什么IPython的行为不同于python的行为？

这与我之前的一个问题Which interpreter is used by ipython?有关，该问题表明IPython和Python交互式外壳都使用相同的python实现，即cpython。

对我来说，IPython 只是一个外壳程序，应该将python代码的解释转发给与python相同的基础解释器。因此，评估相同代码的结果应该相同（当然不是对象的地址，而是重用相同代码的事实）

注意：我可以轻松想象一些原因，解释为什么有时解释器能够为新对象重用相同的内存位置，有时却不能，但是我不能解释为什么行为在这里有所不同，因为两者都使用相同的实现。

这是重复项：对于问这是否是How unique is Python's id()?的重复项的人，答案显然是“否”，我尽力解释上述原因。也许不清楚？

解决方法

尝试通过IPython中的一个源文件两次运行id（[]）。它应该给您与常规Python相同的结果。 同样，由于上述行为，IPython不会导致任何错误。 您可以在每个命令后检查locals（）和globals（）来进一步排除故障或了解更多信息。 看来IPython垃圾会立即收集第一个垃圾。

,

这是一个有趣的发现。交互式shell的id确实看起来更稳定。但是，如果您在shell中进行更多修改，即使在交互式Python shell的同一会话中，您也可以观察到不同的空列表的ID。

>>> id([])
140490599993424
>>> [] is []
False
>>> id([])
140490599925376
>>> id([])
140490599925376
>>> [] is []
False
>>> id([])
140490599993424

iPython中较小的id稳定性可能与垃圾回收有关，但最好向iPython开发人员询问，无论哪种方式，显然iPython都比shell更复杂。

身份有点宽松，不要太依赖

>>> 123456789 is 123456789
True
>>> 12345678923456789 is 123456789123456789
False
>>> frozenset({}) is frozenset({})
True
>>> tuple() is tuple()
True
>>> list() is list()
False
>>> set() is set()
False
>>> id(12345678923456789)
139811567040912
>>> id(12345678923456789)
139811567040912
>>> id(123456789234567893)
139811567040912

找到更多 Two variables in Python have same id,but not lists or tuples

编辑：我删除了有关非确定性在计算中的作用的段落，这引起了话题的讨论。

,

这是一个非常有趣的观察，并且没有很多人意识到IPython在执行语句时使用两个线程。一个线程用于历史记录，另一个用于新执行。每当您依次调用一个no_root_squash时，第二个将在另一个线程中执行，这将使其具有不同的ID。

您可以使用您的发现：

在IPython中：

id

但是，普通的旧python shell使用单个线程，这意味着相同对象的id始终都相同。

在Python shell中

import threading
print(threading.activeCount())  # Should print "2"

# The statetement below should be printing alternating id numbers
# Such as "1 2 1 2" or smthng like that
print(id([])); print(id([])); print(id([])); print(id([]));

更多信息：

• navigable