[Python-Dev] inplace operators and __setitem__

[Phillip J. Eby]

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!


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

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


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