Phillip J. Eby a écrit : > At 05:40 PM 9/28/2005 +0200, Pierre Barbier de Reuille wrote: > >> Rather than closing this as invalid, it would be wiser to update the >> documentation before ! Nothing corresponds to the current behavior. > > > I got my information from here: > > http://www.python.org/2.0/new-python.html#SECTION000700000000000000000
I know ... I already read this page as you already posted it ;) > > >> I think that in this page : >> http://docs.python.org/ref/augassign.html >> >> The last paragraph whould be replace by : >> >> """ >> For targets which are attribute (or indexed) references, the initial >> value is retrieved with a getattr() (resp. __getitem__) and the result >> is assigned with a setattr() (resp. __setitem__). Notice that the two >> methods do not necessarily refer to the same variable. When getattr() >> refers to a class variable, setattr() still writes to an instance >> variable. For example: >> """ >> >> That way it will be clearly defined in the documentation. > > > Actually, the broken part is this sentence: > > """Also, when possible, the actual operation is performed in-place, > meaning that rather than creating a new object and assigning that to the > target, the old object is modified instead.""" > > It is subtly misleading, and would be better stated as: > > """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.""" Indeed ! I missed that one :-S Your proposal should be integrated inside documentation (if anyone knows how to do so ...) !!! > >> Now, one can wonder if the augmented assignment is really an >> improvement. Lots of errors are made because they are counter-intuitive. > > > Huh? > 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. > >> For example, in the standard library, I found very few uses of "+=" with >> a mutable object, and none would be broken if "a += b" is to be >> replaced by "a = a+b". At worst, there will be a performance issue that >> will easily be fixed by using "extend" method for lists and >> corresponding methods for other objects. > > > The intended use case (as I understand it) for augmented assignment is > to allow you to hint that an operation should be done in place *if* it > can be. It means that you are not expecting a new object to be the > result, but are prepared for the possibility it *might* be a new object. > > >> My opinion is, redefining the augmented assignment is a problem given >> the assignment semantic, and perhaps we should get rid of it. > > > How is it a problem? If the assignment semantic weren't what it is, > what would it be good for? You could just write an in-place method and > be done with it. The whole point is that it allows client code not to > care whether it's in-place or not, and to allow implementations to > decide (even at runtime) whether to return a different object or not. 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. 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. Pierre PS: I'm not criticizing the assignment operator semantic which is exactly what is should be ;) -- 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
