Class Variable Access and Assignment

[Steven D'Aprano]

On Fri, 04 Nov 2005 07:46:45 +0000, Antoon Pardon wrote:

>> Because b.a += 2 expands to b.a = b.a + 2. Why would you want b.a =
>><something> to correspond to b.__class__.a = <something>?
> 
> That is an implemantation detail. The only answer that you are given
> means nothing more than: because it is implemented that way.

You keep saying "that's an implementation detail" and dismissing the
question, but that's the heart of the issue. What does b.a += 2 *mean*? It
doesn't mean "sort the list referenced by b.a" -- we agree on that much.
You seem to think that it means "increment the object currently named
b.a by two". But that's not what it means.

b.a += 2 has a precise meaning, and for ints and many other objects that
meaning is the same as b.a = b.a + 2. Yes, it is an implementation detail.
So what? It is an implementation detail that "b.a += 2" doesn't mean "sort
the list referenced by b.a" too.

In some other language, that's precisely what it could mean -- but Python
is not that language.

b.a has a precise meaning too, and again you have got it wrong. It doesn't
mean "search b's namespace for attribute a". It means "search b's
namespace for attribute a, if not found search b's class' namespace, and
if still not found, search b's class' superclasses". It is analogous to
nested scopes. In fact, it is a type of nested scope.

In some other language, b.a could mean what you think it means, but Python
is not that language. That's a deliberate design decision. Nested
attribute search gives the most useful results in the most common cases,
while still being easy to work around in the rare cases where it is not
what is wanted.


>> I'm not saying that it couldn't, if that was the model for inheritance you
>> decided to use. I'm asking why would you want it? What is your usage case
>> that demonstrates that your preferred inheritance model is useful?
> 
> It has nothing to do with a model for inheritance, but with a model of
> name resolution.

Which is designed to act the way it does in order to produce the
inheritance model. You can't have that inheritance model without that name
resolution.


> The hierarchie of searching an instance first in an object and then in
> a class isn't that different from searching first in a local namespace
> and then in a more global namespace.
> 
> When we search names in a function we don't resolve the same name in
> different name spacese each occurence of the same name in the same
> function occurs in the same namespace.

That's because it isn't needed for function namespaces. Names in a
function don't inherit state or behaviour from names in a higher-level
scope. Attribute names in classes do.


> But with class variables we can have that one and the same name
> on a line refers to two different namespaces at the same time.
> That is IMO madness. You may argue that the madness is of little
> importance, you can argue that because of the current implementation
> little can be done about it. But I don't see how one can defend
> it as sane behaviour.

Because inheritance is useful, sensible, rational behaviour for OO
programming.


-- 
Steven.