[Python-Dev] inplace operators and __setitem__
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 += [5,6]
... a *is* mutable, so the author of the bug report did not feel like
its l-value was immutable as he supposed a was the l-value, however
in this case, both "a" and "a" 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
"""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
> 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*
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