Addition of a .= operator
Richard Damon
Richard at Damon-Family.org
Sat May 20 17:18:43 EDT 2023
On 5/20/23 4:15 PM, Peter J. Holzer wrote:
> On 2023-05-20 10:54:59 -0700, Alex Jando wrote:
>> I have many times had situations where I had a variable of a certain
>> type, all I cared about it was one of it's methods.
>>
>> For example:
>>
>> ------------------------------------------------------------
>> hash = hash.hexdigest()
>> ------------------------------------------------------------
>> num = num.value
>> ------------------------------------------------------------
>>
>> So what I'm suggesting is something like this:
>>
>> ------------------------------------------------------------
>> hash.=hexdigest()
>> ------------------------------------------------------------
>> num.=value
>> ------------------------------------------------------------
> I actually needed to read those twice to get their meaning. I think
>
> hash .= hexdigest()
> num .= value
>
> would have been clearer (yes, I nag my colleagues about white-space,
> too).
>
> Do you have any examples (preferably from real code) where you don't
> assign to a simple variable? I feel that
> x += 1
> isn't much of an improvement over
> x = x + 1
> but
> self.data[line+len(chars)-1] += after
> is definitely an improvement over
> self.data[line+len(chars)-1] + self.data[line+len(chars)-1] + after
>
> hp
>
>
For immutable types, it is just syntactic sugar, but for mutable type
there is an important difference
x = []
y = x
x += [1]
changes the list named by y, but
x = []
y = x
x = x + []
does not.
The key is that if a type actually implements the inplace operator, then
using the op= version doesn't bind the name to a new object but mutates
the object to a new value.
This just can't happen (as far as I can figure) for .= unless the object
is defining something weird for the inplace version of the operation,
which is probably best to not actually allow.
--
Richard Damon
More information about the Python-list
mailing list