[Python-Dev] inplace operators and __setitem__
Phillip J. Eby
pje at telecommunity.com
Wed Sep 28 18:52:11 CEST 2005
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
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.
More information about the Python-Dev