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