Python becoming less Lisp-like

[Antoon Pardon]

Op 2005-03-22, Steve Holden schreef <steve at holdenweb.com>:
> 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.

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