[Python-Dev] inplace operators and setitem (original) (raw)

Pierre Barbier de Reuille pierre.barbier at cirad.fr
Wed Sep 28 18:15:35 CEST 2005

Phillip J. Eby a écrit :

At 05:40 PM 9/28/2005 +0200, Pierre Barbier de Reuille wrote:

Rather than closing this as invalid, it would be wiser to update the documentation before ! Nothing corresponds to the current behavior. I got my information from here: http://www.python.org/2.0/new-python.html#SECTION000700000000000000000

I know ... I already read this page as you already posted it ;)

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. Actually, the broken part is this sentence: """Also, when possible, the actual operation is performed in-place, meaning that rather than creating a new object and assigning that to the target, the old object is modified instead.""" It is subtly misleading, and would be better stated as: """Also, when possible, the actual operation is performed in-place, meaning that rather than creating a new object the old object is modified instead. In either case, however, the assignment to the target is still performed."""

Indeed ! I missed that one :-S Your proposal should be integrated inside documentation (if anyone knows how to do so ...) !!!

Now, one can wonder if the augmented assignment is really an improvement. Lots of errors are made because they are counter-intuitive. Huh?

Regularly, you see questions about augmented assignment on Python-tutor mailing list, I often have question in my lab because of problems ... most of the time people learn to avoid these operators in the end ! And my look in the standard library confirmed my intuition about it.

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. The intended use case (as I understand it) for augmented assignment is to allow you to hint that an operation should be done in place if it can be. It means that you are not expecting a new object to be the result, but are prepared for the possibility it might be a new object.

My opinion is, redefining the augmented assignment is a problem given the assignment semantic, and perhaps we should get rid of it. How is it a problem? If the assignment semantic weren't what it is, what would it be good for? You could just write an in-place method and be done with it. The whole point is that it allows client code not to care whether it's in-place or not, and to allow implementations to decide (even at runtime) whether to return a different object or not.

The problem is: this seems to be more a problem than a solution ! There is a huge difference between in-place or not, and I find it very difficult not to consider it. If you have a use-case for this "let the object decide about in-place operation or not" I'd be interested as I found none.

Pierre

PS: I'm not criticizing the assignment operator semantic which is exactly what is should be ;)

-- 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