They don't get pre-bound to some kind of illegal value. The parser determines due to the presence in the function's code of an assignment with that name as object - by STATIC analysis - that the name is local, and therefore generates local references for it. It's the failure of a local read that gives rise to the UnboundLocalError.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
If you want to talk about this as a binding you can, I suppose. In actual fact, though, it's the code object's co_names attribute that says which names are to be regarded as local, as far as I understand it.
You appear to be asking for a very explicit (and extremely ambitious) type of optimization here.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.
Great. I though you were going to start up with the snails again ... :-)
regards Steve -- Meet the Python developers and your c.l.py favorites March 23-25 Come to PyCon DC 2005 http://www.pycon.org/ Steve Holden http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
