In the following code, I don't understand why useless_func
has the same id when it belongs to two different objects?
class parent(object):
@classmethod
def a_class_method(cls):
print "in class method %s" % cls
@staticmethod
def a_static_method():
print "static method"
def useless_func(self):
pass
p1, p2 = parent(),parent()
id(p1) == id(p2) // False
id(p1.useless_func) == id(p2.useless_func) // True
The identity of an object is an 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. In CPython implementation, this is the address of the object in memory.
Variables in Python In Python, every object that is created is given a number that uniquely identifies it. It is guaranteed that no two objects will have the same identifier during any period in which their lifetimes overlap.
A class holds the methods and properties that are shared by all of the objects that are created from it. Although the objects share the same code, they can behave differently because they can have different values assigned to them.
A single class definition can be used to create multiple objects. As mentioned before, objects are independent. Changes made to one object generally do not affect the other objects representing the same class. Each object has its own unique set of data attributes.
This is a very interesting question!
Under your conditions, they do appear the same:
Python 2.7.2 (default, Oct 11 2012, 20:14:37)
[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class Foo(object):
... def method(self): pass
...
>>> a, b = Foo(), Foo()
>>> a.method == b.method
False
>>> id(a.method), id(b.method)
(4547151904, 4547151904)
However, notice that once you do anything with them, they become different:
>>> a_m = a.method
>>> b_m = b.method
>>> id(a_m), id(b_m)
(4547151*9*04, 4547151*5*04)
And then, when tested again, they have changed again!
>>> id(b.method)
4547304416
>>> id(a.method)
4547304416
When a method on an instance is accessed, an instance of "bound method" is returned. A bound method stores a reference to both the instance and to the method's function object:
>>> a_m
<bound method Foo.method of <__main__.Foo object at 0x10f0e9a90>>
>>> a_m.im_func is Foo.__dict__['method']
True
>>> a_m.im_self is a
True
(note that I need to use Foo.__dict__['method']
, not Foo.method
, because Foo.method
will yield an "unbound method"… the purpose of which is left as an exercise to the reader)
The purpose of this "bound method" object is to make methods "behave sensibly" when they are passed around like functions. For example, when I call function a_m()
, that is identical to calling a.method()
, even though we don't have an explicit reference to a
any more. Contrast this behaviour with JavaScript (for example), where var method = foo.method; method()
does not produce the same result as foo.method()
.
SO! This brings us back to the initial question: why does it seem that id(a.method)
yields the same value as id(b.method)
? I believe that Asad is correct: it has to do with Python's reference-counting garbage collector*: when the expression id(a.method)
is evaluated, a bound method is allocated, the ID is computed, and the bound method is deallocated. When the next bound method — for b.method
— is allocated, it is allocated to exactly the same location in memory, since there haven't been any (or have been a balanced number of) allocations since the bound method for a.method
was allocated. This means that a.method
appears to have the same memory location as b.method
.
Finally, this explains why the memory locations appear to change the second time they are checked: the other allocations which have taken place between the first and the second check mean that, the second time, they are allocated at a different location (note: they are re-allocated because all references to them were lost; bound methods are cached†, so accessing the same method twice will return the same instance: a_m0 = a.method; a_m1 = a.method; a_m0 is a_m1 => True
).
*: pedants note: actually, this has nothing to do with the actual garbage collector, which only exists to deal with circular references… but… that's a story for another day.
†: at least in CPython 2.7; CPython 2.6 doesn't seem to cache bound methods, which would lead me to expect that the behaviour isn't specified.
Here is what I think is happening:
p1.useless_func
, a copy of it is created in memory. This memory location is returned by id
p2.useless_func
, a copy of it is created in the same memory address (it was available), which you retrieve using id
again.If you were to run a bunch of other code and check the ids of the instance methods again, I'll bet the id
s would be identical to each other, but different from the original run.
Additionally, you might notice that in David Wolver's example, as soon as a lasting reference to the method copy is obtained the id
s become different.
To confirm this theory, here is a shell session using Jython (same result with PyPy), which does not utilize CPython's reference counting garbage collection:
Jython 2.5.2 (Debian:hg/91332231a448, Jun 3 2012, 09:02:34)
[OpenJDK Server VM (Oracle Corporation)] on java1.7.0_21
Type "help", "copyright", "credits" or "license" for more information.
>>> class parent(object):
... def m(self):
... pass
...
>>> p1, p2 = parent(), parent()
>>> id(p1.m) == id(p2.m)
False
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With