Python becoming less Lisp-like
apardon at forel.vub.ac.be
Tue Mar 22 14:31:10 CET 2005
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
> 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?
More information about the Python-list