Jen Kris wrote:
Avi,
Your comments go farther afield than my original question, but you made some
interesting additional points. For example, I sometimes work with the C API
and sys.getrefcount may be helpful in deciding when to INCREF and DECREF. But
that’s another issue.
The situation I
s can be detached from
that reference too so a link is not permanent.
Have we beaten this one to death yet?
-Original Message-
From: Python-list On
Behalf Of Frank Millman
Sent: Sunday, January 15, 2023 12:47 AM
To: python-list@python.org
Subject: Re: To clarify how Python h
On 2023-01-15 4:36 AM, Roel Schroeven wrote:
Chris Angelico schreef op 15/01/2023 om 1:41:
On Sun, 15 Jan 2023 at 11:38, Jen Kris wrote:
>
> Yes, in fact I asked my original question – "I discovered something
about Python array handling that I would like to clarify" -- because I
saw that Py
Chris Angelico schreef op 15/01/2023 om 1:41:
On Sun, 15 Jan 2023 at 11:38, Jen Kris wrote:
>
> Yes, in fact I asked my original question – "I discovered something about Python
array handling that I would like to clarify" -- because I saw that Python did it that
way.
>
Yep. This is not spec
On Sun, 15 Jan 2023 at 11:38, Jen Kris wrote:
>
> Yes, in fact I asked my original question – "I discovered something about
> Python array handling that I would like to clarify" -- because I saw that
> Python did it that way.
>
Yep. This is not specific to arrays; it is true of all Python objec
Yes, in fact I asked my original question – "I discovered something about
Python array handling that I would like to clarify" -- because I saw that
Python did it that way.
Jan 14, 2023, 15:51 by ros...@gmail.com:
> On Sun, 15 Jan 2023 at 10:32, Jen Kris via Python-list
> wrote:
>
>> The si
On Sun, 15 Jan 2023 at 10:32, Jen Kris via Python-list
wrote:
> The situation I described in my original post is limited to a case such as x
> = y ... the assignment can be done simply by "x" taking the pointer to "y"
> rather than moving all the data from "y" into the memory buffer for "x"
>
I
HECK the reference
> count had not changed but there remain edge cases where a removed reference
> is replaced by yet another new reference and you would have no idea.
>
> Avi
>
>
> -Original Message-
> From: Python-list On
> Behalf Of Jen Kris via Python-list
&
13, 2023 3:22 AM
To: python-list@python.org
Subject: Re: To clarify how Python handles two equal objects
writes:
> 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.
>
change to supply what
you want.
From: Jen Kris
Sent: Friday, January 13, 2023 10:58 AM
To: avi.e.gr...@gmail.com
Cc: python-list@python.org
Subject: RE: To clarify how Python handles two equal objects
Avi,
Thanks for your comments. You make a good point.
Going back to my
on.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
On 2023-01-13 16:57:45 +0100, Jen Kris via Python-list wrote:
> 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
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
writes:
> 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.
>From a functional programming point of view this just looks like a
partially applied function, and with this in mind the behaviour to
r 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
&
uch
> 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 On
> Behalf Of Jen Kris via Python-list
> Sent: Wednesday, J
om: Python-list On
Behalf Of Jen Kris via Python-list
Sent: Wednesday, January 11, 2023 1:29 PM
To: Roel Schroeven
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,
On 2023-01-11 18:49:14 +, Stefan Ram wrote:
> Jen Kris writes:
> >Each name has the same pointer
>
> ... from the C programmer's point of view.
>
> From the Python programmer's point of view, there are no "pointers".
That's just window dressing. Pointers are evil, so we can't have
point
On Tue, 10 Jan 2023 16:59:59 -0500, Thomas Passin
declaimed the following:
>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.
>
However, it has long
I think the key point is that "the operation" doesn't act on "names" but
on "objects" (which are different sort of things), and thus there isn't
an "the other" when talking about the object being operated on.
Thinking of an operation being on a "name" is the mental model error.
The only operat
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
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 explanatio
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). My issue in Python came up because Python can dynamically
change one or the other to a different object (memory block) so
On 11/01/23 11:21 am, Jen Kris wrote:
where one object derives from another object (a = b[0], for example), any
operation that would alter one will alter the other.
I think you're still confused. In C terms, after a = b[0], a and b[0]
are pointers to the same block of memory. If you change tha
On 2023-01-10 22:21, Jen Kris via Python-list 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 th
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
On 1/10/23 12:03, Jen Kris via Python-list 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.
> But on the next iteration we assign arr1 to something
On 1/10/2023 5:11 PM, Chris Angelico wrote:
On Wed, 11 Jan 2023 at 09:08, Thomas Passin wrote:
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.
Just to be
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. When eithe
On Wed, 11 Jan 2023 at 09:08, Thomas Passin wrote:
>
> 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.
Just to be even pickier, Python DOES have an array
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 heavi
Jen Kris via Python-list schreef op 10/01/2023 om 21:41:
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).
As long as they are *identical*, not equal. Identical as in having the
same identity as Python defines it.
I
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
at 3:47 PM
To: Python List
Subject: Re: To clarify how Python handles two equal objects
*** Attention: This is an external email. Use caution responding, opening
attachments or clicking on links. ***
On Wed, 11 Jan 2023 at 07:41, Jen Kris wrote:
>
>
> Thanks for your comments. I'
On Wed, 11 Jan 2023 at 07:41, Jen Kris 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 en
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
On Wed, 11 Jan 2023 at 07:14, Jen Kris via Python-list
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
37 matches
Mail list logo