Bob, Your examples show a and b separately defined. My example is where the definition is a=1; b = a. But I'm only interested in arrays. I would not rely on this for integers, and there's not likely to be any real cost savings there.
Jan 13, 2023, 08:45 by b...@mellowood.ca: > It seems to me that the the entire concept of relying on python's idea of > where an object is stored is just plain dangerous. A most simple example > might be: > >>> a=1 > >>> b=1 > >>> a is b > True > >>> a=1234 > >>> b=1234 > >>> a is b > False > > Not sure what happens if you manipulate the data referenced by 'b' in the > first example thinking you are changing something referred to by 'a' ... but > you might be smart to NOT think that you know. > > > > On Fri, Jan 13, 2023 at 9:00 AM Jen Kris via Python-list <> > python-list@python.org> > wrote: > >> >> Avi, >> >> Thanks for your comments. You make a good point. >> >> Going back to my original question, and using your slice() example: >> >> middle_by_two = slice(5, 10, 2) >> nums = [n for n in range(12)] >> q = nums[middle_by_two] >> x = id(q) >> b = q >> y = id(b) >> >> If I assign "b" to "q", then x and y match – they point to the same memory >> until "b" OR "q" are reassigned to something else. If "q" changes during >> the lifetime of "b" then it’s not safe to use the pointer to "q" for "b", as >> in: >> >> nums = [n for n in range(2, 14)] >> q = nums[middle_by_two] >> x = id(q) >> y = id(b) >> >> Now "x" and "y" are different, as we would expect. So when writing a spot >> speed up in a compiled language, you can see in the Python source if either >> is reassigned, so you’ll know how to handle it. The motivation behind my >> question was that in a compiled extension it’s faster to borrow a pointer >> than to move an entire array if it’s possible, but special care must be >> taken. >> >> Jen >> >> >> >> Jan 12, 2023, 20:51 by >> avi.e.gr...@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....@python.org>> > On Behalf Of Jen Kris via Python-list >> > Sent: Wednesday, January 11, 2023 1:29 PM >> > To: Roel Schroeven <>> r...@roelschroeven.net>> > >> > Cc: >> python-list@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 >> r...@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 >> > >> >> -- >> >> https://mail.python.org/mailman/listinfo/python-list >> > > > -- > > **** Listen to my FREE CD at > http://www.mellowood.ca/music/cedars> **** > Bob van der Poel ** Wynndel, British Columbia, CANADA ** > EMAIL: > b...@mellowood.ca > WWW: > http://www.mellowood.ca > -- https://mail.python.org/mailman/listinfo/python-list