Neil Cerutti wrote: > On 2007-08-11, Alex Martelli <[EMAIL PROTECTED]> wrote: >> Neil Cerutti <[EMAIL PROTECTED]> wrote: >> ... >>> The Python Language Reference seems a little confused about the >>> terminology. >>> >>> 3.4.7 Emulating numeric types >>> 6.3.1 Augmented assignment statements >>> >>> The former refers to "augmented arithmetic operations", which I >>> think is a nice terminology, since assignment is not necessarily >>> taking place. Then the latter muddies the waters. >> Assignment *IS* "necessarily taking place"; if you try the augmented >> assignment on something that DOESN'T support assignment, you'll get an >> exception. Consider: >> >>>>> tup=([],) >>>>> tup[0] += ['zap'] >> Traceback (most recent call last): >> File "<stdin>", line 1, in <module> >> TypeError: 'tuple' object does not support item assignment >> >> Tuples don't support item ASSIGNMENT, and += is an ASSIGNMENT, >> so tuples don't allow a += on any of their items. >> >> If you thought that += wasn't an assignment, this behavior and >> error message would be very problematic; since the language >> reference ISN'T confused and has things quite right, this >> behavior and error message are perfectly consistent and clear. > > Thanks for the correction. I was under the illusion that > sometimes augmented assignment would instead mutate the > object. >
I too thought += was an assignment. And it bit me very painfully a few weeks ago. If it's an assignment, then wouldn't "x += y" mean the same thing as "x = x + y"? If so, why does an assignment to variable a, below, have the *side effect* of changing variable b ... ? >>> a = [1, 2, 3] >>> b = a >>> b [1, 2, 3] >>> a += [4] >>> a [1, 2, 3, 4] >>> b [1, 2, 3, 4] ... but using the "x = x + y" style, the assignment to variable c, below, does *not* have a side effect on variable d (as indeed it should not!)? >>> c = [1, 2, 3] >>> d = c >>> d [1, 2, 3] >>> c = c + [4] >>> c [1, 2, 3, 4] >>> d [1, 2, 3] >>> -- http://mail.python.org/mailman/listinfo/python-list