[Python-Dev] inplace operators and __setitem__

Pierre Barbier de Reuille pierre.barbier at cirad.fr
Wed Sep 28 17:40:06 CEST 2005


Phillip J. Eby a écrit :
> At 03:12 PM 9/28/2005 +0200, Reinhold Birkenfeld wrote:
[...]
> Yes.  See:
> 
> http://www.python.org/2.0/new-python.html#SECTION000700000000000000000
> 
> The purpose of the augmented assignment forms is to allow for the 
> possibility that the item's __i*__ method may or may not exist, and may or 
> may not return the same object.  In the case where there is no __i*__ form, 
> or it does not return the same object, the lvalue *must* be re-bound to the 
> new value, or the semantics break.
> 
> 
> 
>>A case where this matters is here: http://python.org/sf/1306777
> 
> 
> I've closed it as invalid; the behavior is as-defined.

Rather than closing this as invalid, it would be wiser to update the
documentation before ! Nothing corresponds to the current behavior.

I think that in this page :

http://docs.python.org/ref/augassign.html

The last paragraph whould be replace by :

"""
For targets which are attribute (or indexed) references, the initial
value is retrieved with a getattr() (resp. __getitem__) and the result
is assigned with a setattr() (resp. __setitem__). Notice that the two
methods do not necessarily refer to the same variable. When getattr()
refers to a class variable, setattr() still writes to an instance
variable. For example:
"""

That way it will be clearly defined in the documentation.

Now, one can wonder if the augmented assignment is really an
improvement. Lots of errors are made because they are counter-intuitive.
For example, in the standard library, I found very few uses of "+=" with
a mutable object, and none would be broken if "a += b" is to be
replaced by "a = a+b". At worst, there will be a performance issue that
will easily be fixed by using "extend" method for lists and
corresponding methods for other objects.

My opinion is, redefining the augmented assignment is a problem given
the assignment semantic, and perhaps we should get rid of it.

Pierre

-- 
Pierre Barbier de Reuille

INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP
Botanique et Bio-informatique de l'Architecture des Plantes
TA40/PSII, Boulevard de la Lironde
34398 MONTPELLIER CEDEX 5, France

tel   : (33) 4 67 61 65 77    fax   : (33) 4 67 61 56 68


More information about the Python-Dev mailing list