User-defined augmented assignment

Pierre Barbier de Reuille pierre.barbier at cirad.fr
Thu Sep 29 09:38:03 EDT 2005


Hello,

a discussion began on python-dev about this. It began by a bug report,
but is shifted and it now belongs to this discussion group.

The problem I find with augmented assignment is it's too complex, it's
badly explained, it's error-prone. And most of all, I don't see any
use-case for it !

The most common error is to consider that :

 a += b <==> a.__iadd__(b)

when the truth is :

 a += b <==> a = a.__iadd__(b)

which can be very confusing, as the two "a" are not necessarily the
same. It then leads to subtle errors like:

>>> class A(object):
>>>   a = 0

>>> a = A()
>>> b = A()
>>> a.a += 1
>>> A.a += 2
>>> print a.a
1
>>> print b.a
2

Also, the following behavior is pretty confusing :

>>> a = [1]
>>> b = [a]
>>> c = (a,)
>>> b[0] += [2] # Ok, no pb
>>> print a
[1,2]
>>> c[0] += [3]
Traceback (most recent call last):
  File "<string>", line 1, in ?
TypeError: object doesn't support item assignment
>>> print a
[1,2,3]

Then, in the standard library, there is no use-case of user-defined
augmented assignment I could find. Of course, I find the augmented
assignement itself very useful ! I use it a lot with immutable objects
(strings, numbers, tuples, ...) but I tend to avoid it with mutables,
and so it seems in the standard library that uses extensively the
"extend" method of lists and very seldom the "+=" operator with lists.
And even where the "a+=b" is used, it could be replaced with either
"a.extend(b)" or "a = a+b" without bugs.

So, what I would suggest is to drop the user-defined augmented
assignment and to ensure this equivalence :

a X= b <=> a = a X b

with 'X' begin one of the operators.

Pierre



More information about the Python-list mailing list