Antoon Pardon <[EMAIL PROTECTED]> writes:
> Op 2005-11-03, Mike Meyer schreef <[EMAIL PROTECTED]>:
>> Antoon Pardon <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
