To clarify how Python handles two equal objects

[avi.e.gross at gmail.com]

Jen,

It is dangerous territory you are treading as there are times all or parts of objects are copied, or changed in place or the method you use to make a view is not doing quite what you want.

As an example, you can create a named slice such as:

  middle_by_two = slice(5, 10, 2)

The above is not in any sense pointing at anything yet. But given a long enough list or other such objects, it will take items (starting at index 0) starting with item that are at indices 5 then 7 then 9  as in this:

  nums = [n for n in range(12)]
  nums[middle_by_two]

[5, 7, 9]

The same slice will work on anything else:

  list('abcdefghijklmnopqrstuvwxyz')[middle_by_two]
['f', 'h', 'j']

So although you may think the slice is bound to something, it is not. It is an object that only later is briefly connected to whatever you want to apply it to.

If I later change nums, above, like this:

  nums = [-3, -2, -1] + nums
  nums
[-3, -2, -1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11]
  nums[middle_by_two]
[2, 4, 6]

In the example, you can forget about whether we are talking about pointers directly or indirectly or variable names and so on. Your "view" remains valid ONLY as long as you do not change either the slice or the underlying object you are applying to -- at least not the items you want to extract.

Since my example inserted three new items at the start using negative numbers for illustration, you would need to adjust the slice by making a new slice designed to fit your new data. The example below created an adjusted slice that adds 3 to the start and stop settings of the previous slice while copying the step value and then it works on the elongated object:

  middle_by_two_adj = slice(middle_by_two.start + 3, middle_by_two.stop + 3, middle_by_two.step)
  nums[middle_by_two_adj]
[5, 7, 9]

A suggestion is  that whenever you are not absolutely sure that the contents of some data structure might change without your participation, then don't depend on various kinds of aliases to keep the contents synchronized. Make a copy, perhaps  a deep copy and make sure the only thing ever changing it is your code and later, if needed, copy the result back to any other data structure. Of course, if anything else is accessing the result in the original in between, it won't work.

Just FYI, a similar analysis applies to uses of the numpy and pandas and other modules if you get some kind of object holding indices to a series such as integers or Booleans and then later try using it after the number of items or rows or columns have changed. Your indices no longer match.

Avi

-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com at python.org> On Behalf Of Jen Kris via Python-list
Sent: Wednesday, January 11, 2023 1:29 PM
To: Roel Schroeven <roel at roelschroeven.net>
Cc: python-list at python.org
Subject: Re: To clarify how Python handles two equal objects

Thanks for your comments.  After all, I asked for clarity so it’s not pedantic to be precise, and you’re helping to clarify.  

Going back to my original post,

mx1 = [ [ 1, 2, 3 ], [ 4, 5, 6 ], [ 7, 8, 9 ] ]
arr1 = mx1[2]

Now if I write "arr1[1] += 5" then both arr1 and mx1[2][1] will be changed because while they are different names, they are the assigned same memory location (pointer).  Similarly, if I write "mx1[2][1] += 5" then again both names will be updated. 

That’s what I meant by "an operation on one is an operation on the other."  To be more precise, an operation on one name will be reflected in the other name.  The difference is in the names,  not the pointers.  Each name has the same pointer in my example, but operations can be done in Python using either name. 




Jan 11, 2023, 09:13 by roel at roelschroeven.net:

> Op 11/01/2023 om 16:33 schreef Jen Kris via Python-list:
>
>> Yes, I did understand that.  In your example, "a" and "b" are the same pointer, so an operation on one is an operation on the other (because they’re the same memory block).
>>
>
> Sorry if you feel I'm being overly pedantic, but your explanation "an operation on one is an operation on the other (because they’re the same memory block)" still feels a bit misguided. "One" and "other" still make it sound like there are two objects, and "an operation on one" and "an operation on the other" make it sound like there are two operations.
> Sometimes it doesn't matter if we're a bit sloppy for sake of simplicity or convenience, sometimes we really need to be precise. I think this is a case where we need to be precise.
>
> So, to be precise: there is only one object, with possible multiple names to it. We can change the object, using one of the names. That is one and only one operation on one and only one object. Since the different names refer to the same object, that change will of course be visible through all of them.
> Note that 'name' in that sentence doesn't just refer to variables (mx1, arr1, ...) but also things like indexed lists (mx1[0], mx1[[0][0], ...), loop variables, function arguments.
>
> The correct mental model is important here, and I do think you're on track or very close to it, but the way you phrase things does give me that nagging feeling that you still might be just a bit off.
>
> -- 
> "Peace cannot be kept by force. It can only be achieved through understanding."
>  -- Albert Einstein
>
> -- 
> https://mail.python.org/mailman/listinfo/python-list
>

-- 
https://mail.python.org/mailman/listinfo/python-list