To clarify how Python handles two equal objects
Thomas Passin
list1 at tompassin.net
Tue Jan 10 18:28:35 EST 2023
On 1/10/2023 5:21 PM, Jen Kris wrote:
> There are cases where NumPy would be the best choice, but that wasn’t
> the case here with what the loop was doing.
>
> To sum up what I learned from this post, where one object derives from
> another object (a = b[0], for example), any operation that would alter
> one will alter the other.
Let's make sure we're clear here. The way you were doing it, it *looks
like* "one alters the other". But in reality, both are the same thing,
and so when that thing gets altered in some way, both variables will
show the change because they are in fact references to the same object.
As an analogy, if you dye your hair purple and look in a mirror, you
will see your image with the new purple hair. If you look in a
different mirror, you will also see your image with the new purple hair.
They are both reflections of the same object, namely you with your new
purple hair.
The point about the identity of objects contained within other objects
is echoed by the copy and deepcopy operations. copy() copies the
references, deepcopy() makes new objects that are equal to the original
ones. After making a deep copy of a list and assigning it to new
variable, changes in one will no longer show up in the other because the
elements are are no longer the same elements.
> When either is assigned to something else,
> then they no longer point to the same memory location and they’re once
> again independent.
This is right except that in Python, it's better not to think about
their memory locations, because that would basically be an
implementation detail (well, except that if you are going to access them
with C you will possibly need actual locations). Their logical identity
would be better to think about.
> I hope the word "derives" sidesteps the semantic
> issue of whether they are "equal."
>
> Thanks to all who replied to this post.
>
> Jen
>
>
> Jan 10, 2023, 13:59 by list1 at tompassin.net:
>
> Just to add a possibly picky detail to what others have said, Python
> does not have an "array" type. It has a "list" type, as well as some
> other, not necessarily mutable, sequence types.
>
> If you want to speed up list and matrix operations, you might use
> NumPy. Its arrays and matrices are heavily optimized for fast
> processing and provide many useful operations on them. No use
> calling out to C code yourself when NumPy has been refining that for
> many years.
>
> On 1/10/2023 4:10 PM, MRAB wrote:
>
> On 2023-01-10 20:41, Jen Kris via Python-list wrote:
>
>
> Thanks for your comments. I'd like to make one small
> point. You say:
>
> "Assignment in Python is a matter of object references. It's not
> "conform them as long as they remain equal". You'll have to
> think in
> terms of object references the entire way."
>
> But where they have been set to the same object, an
> operation on one will affect the other as long as they are
> equal (in Python). So I will have to conform them in those
> cases because Python will reflect any math operation in both
> the array and the matrix.
>
> It's not a 2D matrix, it's a 1D list containing references to 1D
> lists, each of which contains references to Python ints.
>
> In CPython, references happen to be pointers, but that's just an
> implementation detail.
>
>
>
> Jan 10, 2023, 12:28 by rosuav at gmail.com:
>
> On Wed, 11 Jan 2023 at 07:14, Jen Kris via Python-list
> <python-list at python.org> wrote:
>
>
> I am writing a spot speedup in assembly language for
> a short but computation-intensive Python loop, and I
> discovered something about Python array handling
> that I would like to clarify.
>
> For a simplified example, I created a matrix mx1 and
> assigned the array arr1 to the third row of the matrix:
>
> mx1 = [ [ 1, 2, 3 ], [ 4, 5, 6 ], [ 7, 8, 9 ] ]
> arr1 = mx1[2]
>
> The pointers to these are now the same:
>
> ida = id(mx1[2]) - 140260325306880
> idb = id(arr1) - 140260325306880
>
> That’s great because when I encounter this in
> assembly or C, I can just borrow the pointer to row
> 3 for the array arr1, on the assumption that they
> will continue to point to the same object. Then when
> I do any math operations in arr1 it will be
> reflected in both arrays because they are now
> pointing to the same array:
>
>
> That's not an optimization; what you've done is set arr1
> to be a
> reference to that object.
>
> But on the next iteration we assign arr1 to
> something else:
>
> arr1 = [ 10, 11, 12 ]
> idc = id(arr1) – 140260325308160
> idd = id(mx1[2]) – 140260325306880
>
> Now arr1 is no longer equal to mx1[2], and any
> subsequent operations in arr1 will not affect mx1.
>
>
> Yep, you have just set arr1 to be a completely different
> object.
>
> So where I’m rewriting some Python code in a low
> level language, I can’t assume that the two objects
> are equal because that equality will not remain if
> either is reassigned. So if I do some operation on
> one array I have to conform the two arrays for as
> long as they remain equal, I can’t just do it in one
> operation because I can’t rely on the objects
> remaining equal.
>
> Is my understanding of this correct? Is there
> anything I’m missing?
>
>
> Assignment in Python is a matter of object references.
> It's not
> "conform them as long as they remain equal". You'll have
> to think in
> terms of object references the entire way.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
>
More information about the Python-list
mailing list