Augmented Assignement (was: Re: PEP scepticism)

[Bernhard Herzog]

"Alex Martelli" <aleaxit at yahoo.com> writes:

> "Bernhard Herzog" <bh at intevation.de> wrote in message
> news:6qn16r7i69.fsf at abnoba.intevation.de...
> > I think the main problem (in as much as there actually is a problem) is
> > that whether augmented assignment rebinds the left hand side depends on
> > the type of object, i.e. whether the object implements the appropriate
> 
> Right!  I think the main advantage (in as much as there actually is an
> advantage) is that whether augmented assignment rebids the left hand
> side depends on the type of object. i.e. whether the object implements
> the appropriate methods.  This is called *polymorphism* and is a concept
> of *HUGE* power.

Well, polymorphism is certainly very important and powerful in python
but in an of itself that's no argument in favor of the intricacies of
augmented assignment in Python. Just because something could depend on
the types of the objects involved doesn't mean that it should.

Augmented assignment doesn't actually offer anything that couldn't have
been done with explicit method calls, at least as far as in-place
modification is concerned, because under the covers it actually is a
method call. Explicit is better than implicit.

> > methods, which is very different from normal assignment which always
> > rebinds.
> 
> Do you consider:
>     fee.fie = foo
> and/or
>     fee[fie] = foo
> examples of "normal assignment"? 

In most cases, yes. For the builtin python objects (classes, instances,
modules, list and dictionaries) this form of assignment simply rebinds
and does nothing else.

A class/type can of course override this behavior and it does make sense
in some cases to do so, but deviation from the standard behavior should
be kept to a minimum. Chances are that if you have to deviate too much
you should use normal method calls instead.

> Neither "always rebinds" -- it all
> depends on the type of object, i.e. whether the object (fee) implements
> the appropriate methods (__setattr__, __setitem__).  Augmented
> assignment, like attribute assignment and item assignment, is
> polymorphic. 

I think we have to look carefully at which objects control the behavior
here. 

In fee.fie = foo it's fee that's modified in place and fee.fie doesn't
have anything to say about it. In fee.fie += foo it's either fee or
fee.fie that's modified in place depending on the type of fee.fie, not
fee (although the type of fee comes into play if fee.fie doesn't define
__iadd__). This applies to fee[fie] as well.

> Plain assignment to an _unqualified_ LHS isn't, so
> maybe *THAT* one is the "odd man out"?-)

No. In all three cases (plain assignment, setattr and setitem) the
object the LHS evaluates to does not influence assignment. If it did
there could be very confusing differences between the first assignment
when the LHS doesn't exist yet and the subsequent ones.

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Sketch                                 http://sketch.sourceforge.net/
MapIt!                                               http://mapit.de/