Class Variable Access and Assignment

[Mike Meyer]

"Graham" <graham.abbott at gmail.com> writes:
> Many thanks your explaination cleared up many of the questions I had.
> I know think i can understand the purpose, regardless of my opinion, i
> do however think that one should be able to assign the value in the
> same way it is accessed.

That's not true in lots of cases, and would be a serious restriction
on the language. The rules for where a binding takes place are the way
the are for good reason. Restricting lookups to those rules would make
a number of things more difficult, and would make some features
(cough-closures-cough) nearly useless.

> Given your previous example:
>
>> class Counter(object):
>>      "A mutable counter."
>>      # implementation elided
>
>> class A(object):
>>      instance_count = Counter()
>>      def __init__(self):
>>          self.instance_count.increment()
>
>
> if you changed
>> class A(object):
>>      instance_count = Counter()
>>      def __init__(self):
>>          self.instance_count.increment()
>
> to
>
>> class A(object):
>>      instance_count = 0
>>      def __init__(self):
>>          self.instance_count = self.instance_count + 1
>
> It would not work as planned. I understand all the reasons why this
> occurs, but i dont understand why its implemented this way. Because it
> acts in a different way than you expect.

No, it acts in a different way than *you* expect. It does exactly what
I expect, which is why I didn't write it that way.

> It seems to me that
> self.instance_count should not create a new entry in the __dict__ if a
> class variable of that name is already present anywhere in that objects
> hierarchy.
>
> Does that make sense?

Yes, but such behavior would make Python worse, not better.  Right
now, binding instance.name *always* works(*) on the value of the name
attribute of instance. Creating a special case for when one of the
classes instance belongs to happens to have an attribute "name" would
be less consistent than the current behavior. Yes, the current
behavior is surprising to people who aren't used to dynamic
languages. But there are lots of such things - they're part of the
power of dynamic languages. People who want to program in dynamic
languages just have to get used to those things. That's a lesser price
to pay than having a language cluttered with special cases just to
avoid surprising people who aren't used to the language yet.

> Again thank you for explaination.

You're welcome.

       <mike

*) I almost said "binds", but that's not true. Attempting to bind an
attribute can invoke arbitrary code - but it's got the instance and
attribute name to work with. If you really wanted to, you could create
a class for which trying to set an attribute behaved as you wanted. Be
warned - it's not as easy as it looks.
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.