Op 2005-03-21, Jeff Shannon schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: >> Op 2005-03-18, Jeff Shannon schreef <[EMAIL PROTECTED]>: >> >> I find it odd that you start by saying you still find them very >> consistent and here state there is a slight inconsistency. > > I said that the way that binding a name on a class instance always > creates an instance attribute regardless of the presence of a > similarly-named class attribute is consistent with the way that name > binding works in any scope. This is true. Binding of a name within a > function-local scope works the same way -- bindings are always created > within the narrowest scope unless something is explicitly done to > force other behavior.
But bindings in function scope happen earlier. There already happens some kind of binding at call time. If it wouldn't you wouldn't get an UnboundLocalError but just a NameError. What seems to happen is that at call time all local variable get prebound to somekind of illegal value and if they still have this illegal value when you acces them, python raises the UnboundLocalError To have something consistent with that with instances and classes would mean that the interpreter would find out what attributes could possible be created and do the samekind of prebindind so that if you accessed such an attribute you wouldn't get an AttributeError but something like an UnboundAttributeError. > You pointed out a case in which class/instance attributes behave > slightly differently than local/global names do, and I agree with you > that there is a difference in behavior there. However, that > difference is in the way that bare names are resolved into > local/global references, and *not* in the way that name binding works. Well I don't agree. If name binding would work the same, I would expect other exceptions. > The name binding rules are consistent; the inconsistency is in name > *lookups*, I'm not convinced. The lookup can find out about such cases on intermediate scopes. I doubt that the lookup knows at the start at what level he is going to find the name. So either he keeps the name of local variables of each function somewhere, to do the special case if the variable is local on that level or the name has to be prebound somehow. > and is a case of strong optimization of the standard case > affecting the behavior of an unusual (and strongly discouraged) case. That only affects the behaviour of an unusual (and strongly discouraged) case, doesn't make it consistent. It may be a good argument for choosing to do it this way despite it being (slightly) inconsisten. It is not an argument for it being consistent. > There is a slight inconsistency in something *other* than what the > O.P. was complaining about being inconsistent; I'm recognizing that > inconsistency at the same time as I'm attempting to point out that the > other "inconsistency" really *is* consistent. (I'm also pointing out > that this name-lookup inconsistency is a good example of "practicality > beats purity", because the value of the optimization is, IMO, much > greater than the cost of the inconsistency.) I'm not so sure, but I'm not going to argue this. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
