[Python-Dev] inplace operators and __setitem__

[Pierre Barbier de Reuille]

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