Compound Assignment Operators ( +=, *=, etc...)

[Martijn Faassen]

Tom Christiansen <tchrist at mox.perl.com> wrote:
>      [courtesy cc of this posting mailed to cited author]

> In comp.lang.python, Drew McDowell <drew.mcdowell at msfc.nasa.gov> writes:
> :I looked in the FAQ and couldn't find anything on the Compound Assignment
> :Operators.  (+=, *=, -=, etc..)  Why dosen't Python support them?
> :Is there a easy way to add them?

[motivations against assignment in expressions snipped]

There's an interesting analogy here with the inability to leave off the
{ and } in Perl in a single lined block, like you can in C. The motivation
is that people shoot themselves in the foot with it too often, I recall.

Note that the usual way to do such a readline loop in Python goes like
this:

while 1:
    line = f.readline()
    if not line:
        break
    ... stuff with line here ..

Not too difficult and easy enough to recognize, though it does take some
getting used to.

There were a couple of big threads about assignment in expressions
a while back. In one of those discussions people came up with
interesting ways to do these things without the infinite loop. Often
these center on iterator approaches. It's possible the vaporware Python 2
will extend on that idea.

> As for why you can't write the statement (note: not the expression)

>     x["every"]["good"]["boy"]["does"]["fine"] =  (
> 	x["every"]["good"]["boy"]["does"]["fine"] + 1 )

> as 

>     x["every"]["good"]["boy"]["does"]["fine"] += 1

> The basic reason seems to be that there are some people who believe that
> this kind of thing is cruel and unusual punishment levied upon the poor
> Pascal(ish) programmers purely for sake of brevity.

You can do:

a = x["every"]["good"]["boy"]["does"]
a["fine"] = a["fine"] + 1

Not perfect, perhaps, but a lot easier. It's interesting, but I actually
don't recall running into this problem a lot with Python at all.

> Common arguments in support of such ops include:

>     1) This requires care to avoid mis-duplication:
> 	x["every"]["good"]["boy"]["does"]["fine"] =  (
> 	    x["every"]["good"]["boy"]["deos"]["fine"] + 1 )

You avoid misduplication with the above solution.

>     2) Side effects must be duplicated:
> 	x[every()][good()][boy()][does()][fine()] =  (
> 	    x[every()][good()][boy()][does()][fine()] + 1 )

Partially solved by the above solution.

>     3) It's too long to type.

I'd say solved by the above solution.

>     4) Needless redundancy obscures the real meaning.

I seem to be neutral on this. :)

> Whereas common rebuttals include:

>     1) Toss /bin/ed and get yourself a real editor.

Indeed helpful.

>     2) Don't use side-effects, you wicked creature, you!

When you use side-effects, be careful. :)

>     3) It's more efficient to keep a tmpobj anyway.

I don't get this one. By 'tmpobj', do you mean my solution? Indeed,
it'd be more efficient as you'd avoid (costly) Python name lookups.

>     4) Redundancy can clarify through redundancy.

I plead neutrality once again.

> As to why there's no x++ there, consider how often people from a
> Pascal(ish) background are confused between x+1 and x++ and ++x, and
> you'll begin to see what kind of problems caused it to be vetoed.

I don't think Python was designed for people with a Pascallish background
at all, by the way. 

> But the best reason is probably the one another poster already supplied:
> because Guido didn't like them.  An interesting study would be to check
> the extent to which he also forbids such constructs in his own C code. :-)

When coding in C, code in C; when coding in Python, code in Python. From
what I've heard the Python C sourcecode is well designed; I'm also sure the 
constructs are used in many places.

But again, this problem is something that in practice just does not seem
to happen to me when I program in Python.

Regards,

Martijn