(ob1 is ob2) is equivalent to (id(ob1) == id(ob2))
First, the id function can get the memory address of the object. If the memory addresses of the two objects are the same, then the two objects must be is an object. is equivalent to is. Python source code as evidence.
static PyObject * cmp_outcome(int op, register PyObject *v, register PyObject *w) { int res = 0; switch (op) { case PyCmp_IS: res = (v == w); break; case PyCmp_IS_NOT: res = (v != w); break;
But please see how this situation occurs in the code below?
In [1]: def bar(self, x):
...: return self.x + y
...:
In [2]: class Foo(object):
.. .: x = 9
...: def __init__(self ,x):
...: self.x = x
...: bar = bar
...:
In [3 ]: foo = Foo(5)
In [4]: foo.bar is Foo.bar
Out[4]: False
In [5]: id(foo.bar) == id(Foo.bar )
Out[5]: True
Two objects are judged False by is, but True by id. This is inconsistent with the facts we know. How to explain this phenomenon? The best solution to this situation is to call the dis module to see what the two comparison statements do.
In [7]: dis.dis("id(foo.bar) == id(Foo.bar)")
6
7 DELETE_GLOBAL 29281 (29281) S 10 Store_sLice+111 Slice+2
12 delete_subscr
13 delete_subscr
14 slice+2
15 built_map 10340
18 prINT_EXPR
19 jump_if_orse_pop 118877 E 22 delete_global 29281 (29281)
25 STORE_SLICE+1
In [8]: dis.dis("foo.bar is Foo.bar")
0 BUILD_TUPLE 3
4 DELETE_GLOBAL 29281 (29281) 7 SLICE+2 8 BUILD_MAP 5 DELETE_GLOBAL 29281 (29281) The real situation is that when the . operator is executed, a proxy object is actually generated, foo.bar is Foo.bar When , two objects are generated sequentially and compared on the stack. Because the addresses are different, it must be False, but it is different when id(foo.bar) == id(Foo.bar). Foo.bar is generated first, Then calculate the address of foo.bar. After calculating the address of foo.bar, there will be no object pointing to foo.bar, so the foo.bar object will be released. Then generate the Foo.bar object. Since foo.bar and Foo.bar occupy the same memory size, the memory address of the original foo.bar happens to be reused, so id(foo.bar) == id(Foo. bar) is True.The following content is provided by Leo Jay via email. He explains it more clearly.
The idea of using id(expression a) == id(expression b) to determine whether the results of two expressions are the same object is problematic.
foo.bar This form is called attribute reference [1], which is a type of expression. foo is an instance object, and bar is a method. At this time, the result returned by the expression foo.bar is called method object [2]. According to the documentation:
When an instance attribute is referenced that isn't a data attribute,
its class is searched. If the name denotes a valid class attribute
that is a function object, a method object is created by packing
(pointers to) the instance object and the function object just found
together in an abstract object: this is the method object.
foo.bar itself is not a simple name, but the calculation result of an expression. Method object. In an expression such as id(foo.bar), method object is just a temporary intermediate variable. It is meaningless to use id on temporary intermediate variables.
A more obvious example is,
print id(foo.bar) == id(foo.__init__)
The output result is also True
Look at the id document [3]:
Return the “identity” of an object. This is an integer (or long
integer) which is guaranteed to be unique and constant for this object
during its lifetime. Two objects with non-overlapping lifetimes may
have the same id() value.
CPython implementation detail: This is the address of the object in memory.
Only if you can guarantee that the object will not be destroyed, you can use id to compare two objects. So, if you have to compare, you have to write like this:
fb = foo.bar
Fb = Foo.bar
print id(fb) == id(Fb)
That is, put the results of the two expressions Only by binding to the name and comparing whether they are the same object can you get the correct result.
The same is true for the is expression [4]. The correct result you get now is entirely due to the current implementation details of CPython. The current implementation of is is to calculate the objects on the left and right sides, and then compare whether the addresses of the two objects are the same. If it is changed someday, calculate the left side first, save the address, release the left side, then calculate the right side, and compare again, the result of your is may be wrong. This issue is also mentioned in the official documentation [5]. I think the correct method is like id, first calculate both the left and right sides, and explicitly bind them to their respective names, and then use is to judge.