Class Variable Access and Assignment

Mike Meyer mwm at
Sat Nov 5 00:15:51 CET 2005

Antoon Pardon <apardon at> writes:
> Op 2005-11-04, Mike Meyer schreef <mwm at>:
>> Antoon Pardon <apardon at> writes:
>>> Op 2005-11-03, Mike Meyer schreef <mwm at>:
>>>> Antoon Pardon <apardon at> 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()
> Why do you think so? I see nothing here that couldn't work with
> a reference resolved during compile time.

a - in the global name space - doedn't exist when f is compiled, and
hence can't be dereferenced at compile time. Of course, sufficiently
advanced analysis can figure out that a would exist before f is run,
but that's true no matter how a is added. That isn't the way python

>>> 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.
> No the second is not a direct result of the first. Since there is
> only one reference, I see nothing wrong with the environment
> remebering the reference and reusing it if it needs the reference
> a second time.

Please stay on topic: we're talking about "a = a + 1", not "a += 1".
The former has two references, not one. I've already agreed that the
semantics of += are a wart.

Mike Meyer <mwm at>
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

More information about the Python-list mailing list