Python becoming less Lisp-like

[Antoon Pardon]

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

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