The recent object reference mechanism for Python has been slightly researched, leaving notes for review.
The first one is clear: all objects in "python.
So, what does this mean?
The following code:
#!/usr/bin/env Pythona = [0, 1, 2] # It's a simple list#. Initially, the ID of the list and the individual elements is like this. Print ' origin ' Print ID (a), Afor x in a: print ID (x), XPrint '----------------------' # We changed the first element to print ' after change a[0 ] ' a[0] = 4print ID (a), Afor x in a: print ID (x), XPrint '----------------------' # We'll change the second element to print ' After changes a[1 ' a [1] = 5print ID (a), Afor x in a: print ID (x), XPrint '----------------------' # Look back and read directly write a 0, id is how much print ' How about const 0 ?' Print ID (0), 0
The results of the operation are as follows:
Pastgiftmacbookpro:python pastgift$./reftest.py
Origin
4299760200 [0, 1, 2]
4298181328 0
4298181304 1
4298181280 2
----------------------
After change a[0]
4299760200 [4, 1, 2]
4298181232 4
4298181304 1
4298181280 2
----------------------
After change a[1]
4299760200 [4, 5, 2]
4298181232 4
4298181208 5
4298181280 2
----------------------
How about the const 0?
4298181328 0
From the "origin" section, the address of each element in the list is exactly 24, pointing to the respective data-which reminds me of the array.
After modifying the value of a[0], it is found that the address of a[0] has changed. In other words, the assignment statement actually just makes A[0] point back to the other object. In addition, note that the address of a[0] and the address of a[2] differ by 48 (2 24).
When the a[1] is modified again, the address of a[1] also changes, interestingly, this a[1] address and a[0] address is 24, and the original a[2] Difference 72 (3 24).
Finally, when the address of the number 0 is printed directly, it is found to be exactly the same as the address of the first a[0].
At this point, it is basically possible to say that even the elements in the list are actually references. Modifying the elements in the list is actually modifying the reference.
For class properties in Python, it has been mentioned that "class properties are shared between the same class and its subclasses, and modifying the class properties affects all objects of the same class and its subclasses."
Sounds scary, but after careful study, it is not a big deal.
The following code:
#!/usr/bin/env pythonclass Bird (object): name = ' Bird ' talent = [' Fly ']class Chicken (Bird): Passbird = Bird (); Bir D2 = Bird (); # similar instances Chicken = Chicken (); # Subclass Instances # This is the beginning of the print ' Original attr ' Print ID (bird.name), Bird.nameprint ID (bird.talent), Bird.talentprint ID (bird2 . Name), Bird2.nameprint ID (bird2.talent), Bird2.talentprint ID (chicken.name), Chicken.nameprint ID (chicken.talent) , Chicken.talentprint '----------------------------' # change the name to see bird.name = ' Bird name changed! ' print ' After changing name ' Print ID (bird.name), Bird.nameprint ID (bird.talent), Bird.talentprint ID (bird2.name), Bird2.nameprint ID (bird2.talent), Bird2.talentprint ID (chicken.name), Chicken.nameprint ID (chicken.talent), chicken . Talentprint '----------------------------' # to wash a gift try (modify the element in the class attribute) bird.talent[0] = ' walk ' print ' after changing talent (a List) ' Print ID (bird.name), Bird.nameprint ID (bird.talent), Bird.talentprint ID (bird2.name), Bird2.nameprint ID (bird2.talent), biRd2.talentprint ID (chicken.name), Chicken.nameprint ID (chicken.talent), Chicken.talentprint '---------------------- ------' # for a new talent tree (entire class properties replaced) Bird.talent = [' Swim ']print ' after reassign talent ' Print ID (bird.name), Bird.nameprint ID (bi Rd.talent), Bird.talentprint ID (bird2.name), Bird2.nameprint ID (bird2.talent), Bird2.talentprint ID (chicken.name) , Chicken.nameprint ID (chicken.talent), Chicken.talentprint '----------------------------' # Wash off the new talent tree (modify the elements in the new class attribute) bird.talent[0] = ' Dance ' print ' changing element after reassigning talent ' Print ID (bird.name), Bird.nameprint ID (bird.talent), Bird.talentprint ID (bird2.name), Bird2.nameprint ID (bird2.talent), BIRD2.TALENTPR int ID (chicken.name), Chicken.nameprint ID (chicken.talent), Chicken.talentprint '----------------------------'
Operation Result:
Pastgiftmacbookpro:python pastgift$./changeattributetest.py
Original attr
4301998000 Bird
4301857352 [' Fly ']
4301998000 Bird
4301857352 [' Fly ']
4301998000 Bird
4301857352 [' Fly ']
----------------------------
After changing name
4301986984 Bird Name changed!
4301857352 [' Fly ']
4301998000 Bird
4301857352 [' Fly ']
4301998000 Bird
4301857352 [' Fly ']
----------------------------
After changing talent (a list)
4301986984 Bird Name changed!
4301857352 [' Walk ']
4301998000 Bird
4301857352 [' Walk ']
4301998000 Bird
4301857352 [' Walk ']
----------------------------
After reassign talent
4301986984 Bird Name changed!
4301859512 [' swim ']
4301998000 Bird
4301857352 [' Walk ']
4301998000 Bird
4301857352 [' Walk ']
----------------------------
changing element after reassigning talent
4301986984 Bird Name changed!
4301859512 [' Dance ']
4301998000 Bird
4301857352 [' Walk ']
4301998000 Bird
4301857352 [' Walk ']
----------------------------
At the time of "origin", the same type of object, the same class attribute of the subclass object, is the same address-this is called "sharing".
After modifying name, only the modified Object Name property has changed. This is because the assignment to name is actually a string that is re-referenced. The string itself has not changed. So there is no interaction between the same class and the subclass.
Next, modify the elements in the talent. At this point, the situation changed: the talent properties of the same class and its subclasses all changed together-it's good to understand because they all refer to the same memory address, which refers to the same object.
Next, re-assign the value to talent, which is changed to refer to another object. As a result, only the talent property of this instance has changed. As you can see from the memory address, the talent property of this instance and other instances no longer points to the same object. That is to say, "this instance is already out of the circle".
Then, after the final modification of the elements in the talent, the result of no effect on the other instances is well understood. Because already is "outside the circle person", I again how to toss also is own matter.
Therefore, the "class attribute affects each other in the same category and its subclasses" must have a precondition: After the instance is established, its Class property has never been re-assigned, that is, the class attribute still points to the memory address that was originally pointed to.
Last mention of object properties
The following code:
#!/usr/bin/env pythonclass Bird (object): def __init__ (self): self.talent = [' Fly ']bird = Bird () Bird2 = Bird () # The first scenario is print ' Origin ' Print ID (bird.talent), Bird.talentprint ID (bird2.talent), Bird2.talentprint '------------------- -' # Modify one of the object's properties bird.talent[0] = ' walk ' print ' after changing attribute ' Print ID (bird.talent), Bird.talentprint ID ( bird2.talent), Bird2.talentprint '--------------------' # Dead: Two object's properties point to the same memory address, and then modify bird.talent = Bird2.talentbird.talent[0] = ' swim ' print ' Assign to another attribute and change it ' Print ID (bird.talent), Bird.talentpri NT ID (bird2.talent), Bird2.talentprint '--------------------'
Operation Result:
Pastgiftmacbookpro:python pastgift$./changeattributetest2.py
Origin
4299867632 [' Fly ']
4299760200 [' Fly ']
--------------------
After changing attribute
4299867632 [' Walk ']
4299760200 [' Fly ']
--------------------
Assign to another attribute and change it
4299760200 [' swim ']
4299760200 [' swim ']
--------------------
Because object properties are exactly the same as the content (the properties are generally the same after the initial initialization), they are also assigned to a completely different memory address. Therefore, there is no case of "influence between homogeneous objects".
But if you have one object's properties and another object's properties pointing to the same address, the two (but only between them) are implicated.