Class Variable Access and Assignment

[Bengt Richter]

On 4 Nov 2005 08:23:05 GMT, Antoon Pardon <apardon at forel.vub.ac.be> wrote:

>Op 2005-11-03, Magnus Lycka schreef <lycka at carmen.se>:
>> 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