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

Pierre Barbier de Reuille pierre.barbier at cirad.fr
Thu Sep 29 08:10:54 CEST 2005

Ok, so I took a closer look at the documentation and tried a few things to understand better what you said and I have some remark ...

Phillip J. Eby a ecrit :

At 06:15 PM 9/28/2005 +0200, Pierre Barbier de Reuille wrote:

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. Some example of the problems would help. For the specific bug report being discussed, I don't understand why someone would use augmented assignment with an immutable lvalue, since x |= y is short for x = x | y, which is clearly invalid on the face of it if x is a tuple member!

Well, the problem is:

a = ([1,2], [3,4]) a[0] += [5,6]

... a[0] is mutable, so the author of the bug report did not feel like its l-value was immutable as he supposed a[0] was the l-value, however in this case, both "a" and "a[0]" are l-values !

Otherwise, a very common problem (encounter regularly with labmates):

def foo(a,b): a += b return a a = 3 b = 4 c = foo(a,b) # Works fine as intended d = [1,2] e = [3,4] f = foo(d,e) # Oops ... d is modified

Of course, actual code is much more complex, but the problem can be reduced to that most of the time.

Also, on your sentence (which I find much more accurate than the current one): """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."""

I would add some pseudo-code equivalence like, if "iadd" is defined:

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

which I believe is true from the look at the pseudo-code generated at compile-time. Like this, it is easier to remember and much less subject to interpretation than with human-language sentences ;)

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. Consider string addition. The fact that string concatenation can be implemented with += allows a string to consider based on its refcount to return a new string or to modify itself in-place. If someone uses a = b + c, it may be assumed that they still desire a reference to b, and that therefore the operation cannot be done in-place. If they use a += b, then this is a hint that an in-place operation is desirable.

However, the implementation makes no use of the operator ! First, there is no "iadd" in the "str" class, second documentation says that "a+=b" and "a=a+b" are both optimized. So this does not validate for a use-case ^_^

So, there are two features of augmented assignment: 1. It is a shortcut for spelling out the full assignment 2. Types that override augmented assignment methods may optimize in-place operations, without the need for client code to change.

Sure, I understood ... still I do not see any need for that, while I can see a bunch of problems !

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.

The whole point of it is that I don't need to care whether a particular use is such or not. I simply say what the code intends, and then if somebody needs to pass in something different, or the behavior of some other part of the system changes, then I get that for free. Looking for a specific use case for that is like looking for a use case for duck typing. That is, everything is a use case for it, because the point isn't the initial state of the system. The point is what happens when you change the system.

My point here is: if the syntax causes a problem and does not solve any, why would we keep it ?

As for duck-typing use cases are plenty ! A huge part of my code use benefit of duck-typing and so does the Python library, so there are use-cases !

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