Very minor point: be careful comparing IDs the way you do in the REPL (i.e., without keeping a reference to the previous object)--since the old one is released, it's possible that the memory address is reused and the ID of the new object ends up being the same, even though the object is different, which can have misleading results:
Python 2.7.10 (default, Oct 23 2015, 19:19:21)
[GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class A:
... def b(self): pass
...
>>> A.b
<unbound method A.b>
>>> hex(id(A.b))
'0x104e2c0a0'
>>> hex(id(A.b))
'0x104daeb90'
>>> hex(id(A.b))
'0x104daeb90'
Actually not related. The case in the article is about late-binding methods to object instances (creating a new object on each access) - whereas in python 2 the "unbound method" was a lazy creation on access, and in python 3 an unbound method is just a reference to a bare function in the class' name space. The lazy evaluation is from the descriptor protocol in python (see the links in TLA).
The case you point out is because the python bytecode compiler will intern raw values for some items - e.g. string literals, some integer values, and so on. More on interning: https://en.wikipedia.org/wiki/String_interning
The `is` operator is the same amount of strict in all examples here and in the article: it compares the identities (in CPython, this is essentially the memory address) of two objects.
The reason, in your example, that `is` returns different results is that small integers are "interned"; i.e., the literal 100 always references the exact same integer object, whereas 1000 will cause an integer to be allocated. (So a and b, while both represented 1000, are stored twice in memory.)
Note that the descriptor protocol itself is not causing this behavior. What actually happens here is that functions are descriptors (they implement __get__()) that generate the instancemethod object on attribute access.
More info here: https://wiki.python.org/moin/FromFunctionToMethod
13 comments
[ 2.7 ms ] story [ 33.0 ms ] threadThe case you point out is because the python bytecode compiler will intern raw values for some items - e.g. string literals, some integer values, and so on. More on interning: https://en.wikipedia.org/wiki/String_interning
The reason, in your example, that `is` returns different results is that small integers are "interned"; i.e., the literal 100 always references the exact same integer object, whereas 1000 will cause an integer to be allocated. (So a and b, while both represented 1000, are stored twice in memory.)
Is there a place for raising documentation bugs?
https://bugs.python.org/issue23702