Class Variable Access and Assignment

[Antoon Pardon]

Op 2005-11-07, Christopher Subich schreef <csubich.spam.block at spam.subich.block.com>:
> Antoon Pardon wrote:
>> Op 2005-11-04, Christopher Subich schreef <csubich.spam.block at spam.subich.block.com>:
>>>it's the Python 
>>>idiosyncracy about operations on mutable types.  In this case, += 
>>>mutates an object, while + returns a new one -- as by definition, for 
>>>mutables.
>> 
>> 
>> It is the combination of the two.
>> 
>> If python had chosen for an approach like function namespaces, the
>> problem wouldn't have occured either. What would have happened then
>> is that the compilor would have noticed the a.x on the right hand
>> side and based on that fact would then have deciced that all a.x
>> references should be instance reference (at least in that function
>> block). The a.x += ... would then result in an AttributeError being raised. 
>
> Problem:
> """
> class B:
>     x = 1
> classx = b()
> instx = b()
> instx.x = 5
>
> def addtox(o):
>     o.x += 1
>
> addtox(instx)
> print B.x # 1
> print instx.x # 6; we both agree on this one
> addtox(classx) # You argue this should AttributeError
> print B.x # ?! -- 1 currently, you argue 2 if no error
> print class.x # we both agree 2, if no error
> """
>
> a.x is /not/ a namespace issue at all; it's an attribute issue.
>
> .x is not a name, it is an attribute.

This may be a meaningfull distinction in the current implementation
but IMO it is less meaningfull to make such a distinction conceptually.

x is a name and proceeding it with a. is just a way of deciding in
which namespace the x is to be searched.

> Python namespaces are lexically 
> scoped, not dynamically scoped; if, as you argue, .x should be a name in 
> a namespace, then you argue above that addtox in the above should work 
> on instx but fail on classx.  But this /cannot be determined at compile 
> time/, because the attribute space is attached to the object passed in 
> as the parameter.

That depends on what you allow in the langauge. Allowing declarations
in the language could take care of that. 

You could also decide scope per scope what is to be happend. If
somewhere in the scope there is a line a.x = ..., then within that
scope all 'a.x' refer to the object. In other scope a.x is decide
as it is now.

> I repeat: this is not a name issue at all, it is an attribute issue. 

Why make such a big distinction between the two?

> Python's behaviour is counterintuitive from some angles, but it is the 
> only behaviour that is consistent with attributes in general, given the 
> signature of __iadd__ as-is.

If you mean the only behaviour that is consistent with the current
python attribute implementation. I can accept that. But as you have
worded it, it seems way to general, almost claiming that any language
that does it differently is not consistent. Maybe I misunderstood.

-- 
Antoon Pardon