Addition of a .= operator

[Richard Damon]

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