Class Variable Access and Assignment

Mike Meyer mwm at mired.org
Fri Nov 4 05:15:27 EST 2005


Antoon Pardon <apardon at forel.vub.ac.be> writes:
> Op 2005-11-03, Mike Meyer schreef <mwm at mired.org>:
>> Antoon Pardon <apardon at forel.vub.ac.be> writes:
>>>> What would you expect to get if you wrote b.a = b.a + 2?
>>> I would expect a result consistent with the fact that both times
>>> b.a would refer to the same object.
>> Except they *don't*. This happens in any language that resolves
>> references at run time.
> Python doesn't resolve references at run time. If it did the following
> should work.

You left out a key word: "all".

> a = 1
> def f():
>   a = a + 1
>
> f()

If Python didn't resolve references at run time, the following
wouldn't work:

>>> def f():
...  global a
...  a = a + 1
... 
>>> a = 1
>>> f()
>>> 

> But letting that aside. There is still a difference between resolving
> reference at run time and having the same reference resolved twice
> with each resolution a different result.

The second is a direct result of the first. The environment can change
between the references, so they resolve to different results.





>> Changing that would be changing a fundamental
>> - and *important* - feature of Python. Arbitrary restrictions to
>> prevent a single case of this from doing something people who aren't
>> used to suvh behavior are kludges, and would constitute a wart on the
>> language, pure and simple.
> Python already has its warts. If you want to argue that fixing this
> would make a bigger wart then the wart it is now. Fine I will accept
> that.

I've already argued that the kludges suggested to "solve" this problem
create worse problems than this. This is a simple case of something
being unexpected to those used to less dynamic languages. The other
solutions break useful functionality, and require adding special cases
to the language - which aren't special enough to break the rules.

	<mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.



More information about the Python-list mailing list