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
--
https://mail.python.org/mailman/listinfo/python-list
