PEP 203 - Augmented Assignments

[Huaiyu Zhu]

On Thu, 20 Jul 2000 22:53:38 -0500, Eric Jacobs <none at none> wrote:
>
>But it would only be allowed to modify itself in either case if
>the statement would have deallocated the old object! That can't
>be known from looking at the expression!
>
>Suppose x is a list. The proposal would have
>
>    y = x
>    x = x + [7, 8, 9]
>
>and
>
>    y = x
>    x += [7, 8, 9]
>
>doing different things!
>
>
>That may be okay, of course, but the difficulty is that in C,
>x += really _is_ a short hand for x = x +, and people would be
>liable to use it that way in Python. They'd be changing the
>meaning of their programs without realizing it... lots of bugs
>and unnecessary confusion there.

I'd disagree here.  This difference is one of the key reason that += is
called for in the first place.  And it is the brilliant point in this PEP. I
do not think += should be compatible with C.  In python the = itself is by
reference, unlike C.

>If operators like += were to enter Python, I would highly recommend
>that they mean the same as in C, because that's where most users
>are familiar with them. That is, "x += 1" can be used as a substitute
>for "x = x + 1". Lazy fingers will want to substitute that!

New operators for lazy fingers is probably not a good reason.  New
Python users from C have to get used to things like

b = a
do_something_on(b)

and expect a getting changed.  If you translate this into pointers to make
it understandable in C, then the same analysis can be applied to make +=
understandable.

Huaiyu