It’s a recursion error, yeah.
With those names, SyntaxError. But I don’t think that’s what you wanted to hear. 
I don’t think it would make sense.
Firstly, you should definitely use distinct names for an object and for a method of an object, otherwise one would never know what the variable name stands for at a given moment (when reading the code).
As others said, this would be confusing as well for human readers as for debuggers.
Secondly, this would be completely different from the usual *= operators, which always have the meaning : modify the (left hand side object) “in place”(if possible) by applying the operation (e.g., add 1 to the number, append something to the list, …)
but here you want to replace the variable name to refer to something else, so it’s not a modification of the (left hand side object), but a change of the variable which will thereafter point to some different object (namely, the method of the former object).
No other assignment operator (except for =) does something of that kind.
1 Like
All of the augmented assignment operators can do this kind of replacement, and it’s probably more common than actual in-place modification. Tell me, how often do you do this?
x = [1, 2, 3]
x += [4, 5]
Occasionally perhaps? It definitely happens, but not all that much. What about this, though?
n = 0
n += 1
Yep, this is incredibly common. When += is used with integers, strings, or any other immutable type, it MUST work exactly as you’re describing - replacing the object with something else. Conceptually, it is still a “modification” (you’re changing n to be a value that’s 1 greater than it was), but it will thereafter point to some different object just like you were saying.
There are many arguments against this, but that isn’t one of them.
2 Likes
but here you want to replace the variable name to refer to something else, so it’s not a modification of the (left hand side object), but a change of the variable which will thereafter point to some different object
[…]
No other assignment operator (except for =) does something of that kind.
Because a lot of the basic types are immutable (numbers, strings, tuples), the augmented assignment operators all do that for those.
>>> x = 1; x; x_id = id(x); x_id
1
140704440574760
>>> x += 1; x; id(x); id(x) == x_id
2
140704440574792
False
When you “modify” an instance of an immutable type like a str or an int, what you’re really doing is generating a new instance, putting it in the place of the old one, and then Py_DECREFing the old one. The old object isn’t modified at all, and, if it has other references, can still be found floating around in memory somewhere.
Seems quite specialised
[…]
I can’t see it being used generally.
The same can be said about Python’s matmul @ operator. It’s basically never used outside of interaction with mathematical libraries.
I’d also like to add that for users of other programming languages, this syntax could end up pretty confusing, because .= is often used for broadcasting (mapping) assignment, e.g. in Julia:
x: List = [1, 2, 3]
x .= 2
# returns [2, 2, 2]