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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
