Python becoming less Lisp-like

[Steve Holden]

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
> 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.

> 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 
>>*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/