In python, the result of the following code will not surprise you:
Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v.1600 64 bit (AMD64)] on win32 Type "copyright", "credits" or "license()" for more information. >>> a=345 >>> b=a >>> a is b True >>>
That's right, in python everything is an object, and objects are passed by reference. When you assign a value, it doesn't matter if the object is newly created or if it already exists, you are assigning a reference to that object to the variable. So here a is actually the same object as b, and a is b is true!
Of course anyone who knows a little bit about python I'm sure will know the above. But the result of the following code is not very understandable:
>>> c=256 >>> d=256 >>> c is d True >>> e=257 >>> f=257 >>> e is f False >>>
We assign c to the integer value 256, d to 256, e to 257, and f to 257. But when the is operation is performed on c with d and e with f, we find that the results are different.
What's the reason?
--This is determined by the buffer pool mechanism for integer objects in python.
Almost all built-in objects in python will have their own unique object pooling mechanism.
1. Small integer objects - small integer object pools
In real programming, integers with smaller values, such as 1,2,29, etc., may occur very frequently. And in python, all objects exist with the system heap. Think about it? If a small integer occurs very often, then python will have a lot of malloc/free operations, which greatly reduces the efficiency of the operation, and will cause a lot of memory fragmentation, seriously affecting the overall performance of Python.
In python 2.5 and even 3.3, numbers with small integers between [-5,257) are cached in the small integer object pool.
That's why for c is d and e is not f.
2. Large Integer Objects - Generic Integer Object Pooling
As you can see from the above, python caches small integers completely in the small object cache. The python environment provides a block of memory for large integers to rotate through. The python runtime environment provides a block of memory for large integers to rotate through, often referred to as the general purpose integer object pool. This means that large integers are actually cached. The pool is organized in a chained table, so that e and f are different nodes in the chain, even though they have the same value. This means that e and f are not objects at all. As for why e and f are organized as two nodes if they are cached, I don't quite understand.
Tell me my opinion: I think semantically e=257 and f=257 are themselves supposed to be two different objects (this is different from object assignment). The existence of the integer buffer pool makes people think that only one integer can exist in the buffer pool, and it cannot be duplicated. But there's no essential difference between organizing e and f as one node or two nodes in the integer buffer pool, is there (other than wasting a bit of memory).
summarize
Above is the entire content of this article, I hope the content of this article for your study or work has a certain reference learning value, thank you for your support. If you want to know more about the content please check the following related links