Issue 33685: Instances bound methods with different memory addresses but sharing same id (original) (raw)
Different instances should have different bound method ids, since they have different memory addresses, isn’t it? Example:
I have a class and two instances:
class MyClass:
def something():
pass
a = MyClass()
b = MyClass()
If we print a.something
and b.something
, we can see that they have different memory addresses:
a.something
<bound method MyClass.something of <__main__.MyClass object at 0x103438588>>
b.something
<bound method MyClass.something of <__main__.MyClass object at 0x10342add8>>
This clear indicates that they aren’t the same, and we can confirm that comparing both using the is
operator:
a.something is b.something False
But the identity of both indicates that they are the same, according with the doc of is
and id
:
id(a.something) 4350192008
id(b.something) 4350192008
The documentation of is
says:
The operators is and is not test for object identity: x is y is true if and only if x and y are the same object. x is not y yields the inverse truth value. [6]
ref: https://docs.python.org/2/reference/expressions.html#is
And the documentation of id
says:
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.
Thanks!
ID numbers in Python are only guaranteed to be unique for the lifespan of the object. In CPython they can be re-used. (In other implementations, like Jython and IronPython, IDs are allocated as sequential numbers and won't be reused.)
The other fact you may be missing is that method objects are generated on the fly each time you look them up. So:
py> class X: ... def method(self): pass ... py> x = X() py> a = x.method py> b = x.method py> a is b False
So your example is now understandable: you generate a method object, get its ID, and then the method object is garbage collected, allowing the ID to be reused. Which in this case it is. Whether it is or isn't re-used is an accident of implementation.
In other words: nothing to see here. Its not a bug, just the normal behaviour of IDs and garbage collection.