Op 2005-03-22, Steve Holden schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: >> 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 >> > 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. > > 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.
And does this code object know which non-local names are on an intermediate level and which are global? If not it seems the binding has to be more than just the code object's co_names attribute. >> 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 appear to be asking for a very explicit (and extremely ambitious) > type of optimization here. You misunderstand. I don't ask for this. I just argue that this is what should happen in order to make what happens in function scope and what happens with attributes (more) consistent with each other. What I was wondering, doesn't __slots__ do something like this? -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list