Python becoming less Lisp-like
steve at holdenweb.com
Tue Mar 22 14:01:11 CET 2005
Antoon Pardon wrote:
> Op 2005-03-21, Jeff Shannon schreef <jeffshannon at gmail.com>:
>>Antoon Pardon wrote:
>>>Op 2005-03-18, Jeff Shannon schreef <jeffshannon at gmail.com>:
>>>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
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.
> 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 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
> 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 ... :-)
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/
More information about the Python-list