Gregory D. Weber schreef: > 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.
It is an assignment, but not only an assignment: first either the creation of a new object (in case of immutable objects) or the modification of an existing object (in case of mutable objects), than an assignment. > If it's an assignment, then wouldn't "x += y" mean the same thing as "x = x + > y"? No: - x += y, x is only evaluated once - in x += y, the operation is performed in-place if possible, meaning that (quoting from the language reference): rather than creating a new object and assigning that to the target, the old object is modified instead > If so, why does an assignment to variable a, below, have the *side effect* of > changing variable b ... ? > >>>> a = [1, 2, 3] -> A list is created and assigned to a >>>> b = a -> That list is also assigned to b >>>> b > [1, 2, 3] >>>> a += [4] -> The list is modified (the list [4] is added to it) and assigned to a. It was already assigned to a, so that assignment doesn't do very much in this case. But it is performed. >>>> a > [1, 2, 3, 4] >>>> b > [1, 2, 3, 4] -> Both a and b are still bound to the original (but now modified) list object > ... 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] -> A list is created and assigned to c >>>> d = c -> That list is also assigned to d >>>> d > [1, 2, 3] >>>> c = c + [4] -> A new list object is created (the sum of the original one and the list [4]) and assigned to c >>>> c > [1, 2, 3, 4] -> c is now bound to the new list object >>>> d > [1, 2, 3] -> ... while d is still bound to the original list object I hope this clears up things a bit... -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven -- http://mail.python.org/mailman/listinfo/python-list
