On 2006-07-17, Paul Boddie <[EMAIL PROTECTED]> wrote: > Antoon Pardon wrote: >> >> What the language reference should have said IMO is that in case x >> is an attribute reference, index or slicing, the primary expression >> will be evaluated only once, as will be the index or slice in the >> two latter cases. > > I think the difficulty here for the author of this particular section > of the reference is in describing the mechanisms at work whilst keeping > the description at a conceptual level which can be directly connected > to the source text in a program.
Sure! However the author of the augmented assignment reference uses a concept that seems not be a pythonic concept: a target evaluation. Call it an lvalue, a lefthand evaluation if you prefer, but in the assignment reference it is never mentioned. Each time the word evaluation is used, it is the evaluation of an expression, never a target. Sure sometimes such a expression is part of a target, but the evaluation never reaches a point where the result is the evaluation of a target: So why doesn't the autor of the augmented assignment reference limit himself to the same concepts used in the assignment reference? Now maybe I'm just not bright enough, so maybe you can explain what something like col['t'] is evaluated to in a statement like: col['t'] = exp > However, apart from providing a vague > intuition about how augmented assignment must work, the description > doesn't answer all questions effectively, particularly in cases where > the actual assignments are not simple local/global name binding > operations. > > One way to consider augmented assignment is as a statement formulated > in the following way: > > setvalue(namespace, name, op(getvalue(namespace, name), expr)) > > Consider an augmented assignment on a local name: > > a += b > > This could be phrased as follows: > > setname(locals, "a", add(getname(locals, "a"), b)) > > Or really: > > setname(locals, "a", add(getname(locals, "a"), getname(locals, "b"))) > > Consider an augmented assignment on an attribute: > > a.b += c > > This could also be phrased similarly: > > setattr(a, "b", add(getattr(a, "b"), c)) > > And consider an augmented assignment on an item: > > a[b] += c > > This too is phrased similarly: > > setitem(a, b, add(getitem(a, b), c)) > > So, as long as you're willing to accept that the setvalue class of > operations (setname, setattr, setitem) aren't really evaluating the > target of the assignment - strictly, the thing being replaced in the > assignment - then only the getvalue class of operations (getname, > getattr, getitem) are causing the evaluation of the target. And since > setname is just a normal name binding assignment which we know doesn't > cause the target to be evaluated, we can assume that the other > operations in that class behave similarly. Well maybe I'm missing your point entirely but would you be so friendly, as to rephrase the following statements too: a = a + b a.b = a.b + c a[b] = a[b] + c Because as far as I can see the rephrasing of these statements will result in exactly the same results as their augmented assignment counter parts. So following your logic above, we would have to come to the conclusion that the "targets" of these statements are evaluated once too. This while the language reference suggests they are evaluated twice. IMO the language reference sugest that the stament: a[i] += [b] is more effective than: a[i] = a[i] + [b] IMO it suggests that the augmented assignment version is just as effective as: a[i].append(b) Because, i hope, we agree that a[i] is evaluated only once here! So we have here three statements all which result in a similar result one in which the number of evaluations of a[i] is under dispute, one in which the number of evaluations is suggested to be two one in which the number of evaluations is one. Yet the work done in the augmented version of this example is almost the same as in the normal assignment, the difference is negligible IMO and both version differ about the same with the append version which will have to do about half what the other versions had to do, depending on how expensive the __xetitem__ methods are. > Now, one aspect of evaluation has been skipped in the above > explanation: what if we have a "complicated" expression on the left > hand side? Consider this: > > a.f().x += y > > We could naively write this as follows: > > setattr(a.f(), "x", add(getattr(a.f(), "x"), y)) > > However, it looks like we are evaluating at least part of the left hand > side twice. Thus, we need to be a bit clearer about what really > happens: > > namespace = a.f() > setattr(namespace, "x", add(getattr(namespace, "x"), y)) > > In order to avoid double evaluation, we first obtain the target > namespace (or itemspace, I suppose). Then, we perform the operations as > stated above. Yes, and what you are doing here is eliminating the double evaluation of the primary. In a statement like a.f().x = ... the a.f() part is the primary according to the assignment reference. > So, to conclude, augmented assignment involves the evaluation of any > expression which gives the target namespace (trivial in the case of > local/global name binding, non-trivial otherwise), then a compound > operation of the form given above involving two classes of operations, > each providing operations to act on names, attributes and items. This seems not be complete, if the target is a list, there is no target namespace. That is why I used "primary" in my proposal, because it catches all cases and it is also the term used in the assigment reference. > I doubt that this explanation is simple, clear or efficient enough for > the language reference, Would you mind explaning, what you think is not simple, clear or efficient enough about my proposed wording? Just curious. > but then any explanation shouldn't be > constrained in terms of complexity in a way that, for example, a > tutorial explanation should be. Despite cries of "you must get it now!" > from various quarters, I think this thread has been informative, and > I'd like to thank you for bringing this matter to the group's > attention, Antoon. Your welcome. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list