On 4 Nov 2005 08:23:05 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote: >Op 2005-11-03, Magnus Lycka schreef <[EMAIL PROTECTED]>: >> Antoon Pardon wrote: >>> There is no instance variable at that point. How can it add 2, to >>> something that doesn't exist at the moment. >> >> Because 'a += 1' is only a shorthand for 'a = a + 1' if a is an >> immutable object? Anyway, the behaviour is well documented. >> >> http://docs.python.org/ref/augassign.html says: >> >> An augmented assignment expression like x += 1 can be rewritten as x = x >> + 1 to achieve a similar, but not exactly equal effect. In the augmented >> version, x is only evaluated once. > >Then couldn't we expect that the namespace resolution is also done >only once? > >I say that if the introduction on += like operators implied that the >same mentioning of a name would in some circumstances be resolved to >two different namespaces, then such an introduction would better have >not occured. > >Would it be too much to ask that in a line like. > > x = x + 1. > >both x's would resolve to the same namespace? > I think I would rather seek consistency in terms of order of evaluation and action. IOW, the right hand side of an assignment is always evaluated before the left hand side, and operator precedence and syntax defines order of access to names in their expression context on either side.
The compilation of function bodies violates the above, even allowing future (execution-wise) statements to influence the interpretation of prior statements. This simplifies defining the local variable set, and allows e.g. yield to change the whole function semantics, but the practicality/purity ratio makes me uncomfortable ;-) If there were bare-name properties, one could control the meaning of x = x + 1 and x += 1, though of course one would need some way to bind/unbind the property objects themselves to make them visible as x or whatever names. It might be interesting to have a means to push and pop objects onto/off-of a name-space-shadowing stack (__nsstack__), such that the first place to look up a bare name would be as an attribute of the top stack object, i.e., name = name + 1 if preceded by __nsstack__.append(my_namespace_object) would effectively mean my_namespace_object.name = my_namespace_object.name + 1 by way of logic like if __nsstack__: setattr(__nsstack__[-1], getattr(__nstack__[-1], name) + 1)) else: x = x + 1 Of course, my_namespace_object could be an instance of a class that defined whatever properties or descriptors you wanted. When you were done with that namespace, you'd just __nsstack__.pop() If __nsstack__ is empty, then of course bare names would be looked up as now. BTW, __nsstack__ is not a literal proposal, just a way to illustrate the concept ;-) OTOH, is suppose a function could have a reseved slot for a name space object stack that wouldn't cost much run time to bypass with a machine language check for NULL. BTW2, this kind of stack might play well with a future "with," to guarantee name space popping. Perhaps "with" syntax could even be extended to make typical usage slick ;-) Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list