Theoretical question about Lambda

[Alex Martelli]

Steve Holden wrote:
        ...
>>    def test():
>>       print x
>>       x = 42
>>
>> raises an error because the (empty, error-causing) binding for x is
>> already in force when the "print" statement executes, before the "="
>> is even reached.
>>
> So, it appears that you think binding is the implicit declaration
> assoicated with assignment to a name inside a particular scope? If so, it
> would seem particularly perverse of the implementors to have chosen the
> message
> 
> "Unbound local variable"
> 
> to indicate this situation. Clearly they regard the word "binding" as the
> act of associating a value with a name (which is to say, making an entry
> into the [admittedly conceptual] dictionary associated with a particular
> namespace).

You're both right.  You (and I, when I talk about Python, and the author
of this errormessage) use 'binding' in the simple Python sense of
'associating a name [in a wide sense of the word 'name', btw] with an
object [aka value]'.  Paul is using it in a different sense -- the
association of a name [stricto sensu] with the _scope_ to which it
belongs.  It's damnably hard to find definitions of "binding" on typical
online computer-lexicons, etc.  *MY* priority is to wean Python students
away from their typical conception (THAT one is indeed easy to find on
online lexicons &c:-) that assignmenr "fills a variable with a value",
"places a value into a variable", etc.  The "into", "fill", &c, that are
connotated by "assignment", give exactly the wrong idea and make
learning Python much harder than it needs to be.


> Paul, I'm afraid Alex isn't the only one who completely fails to
> understand your insistence on a distinction between binding and what you
> apparently call assignment (but which Alex and I would, I suspect, simply
> call rebinding).

Actually, I don't think I can say I completely fail to understand the
distinction -- *Python* doesn't make any such distinction (so trying to
make it is counterproductive when thinking in Python, coding Python,
teaching Python, etc), but (e.g.) Lisp does, as do other languages.

On one level is the issue of "what scope/namespace is this barename
in".  In C++, you can say "using somespace::thisname;" and this
means that a bare use of 'thisname' now (in this scope) refers to
somespace::thisname.  This has NOTHING to do with the VALUE that
namespace refers to or contains (which is set separately), but just
with delineating whether when you just say 'thisname' you mean
'somespace::thisname' or rather 'theotherspace::thisname'.  The
only mechanism that Python has that is vaguely reminiscent of this
is the global statement.

On another level is the issue of "what value this name refers to",
which is what you and I and the Python doc authors call binding.
For example,
        def foo(): pass
among other things establishes or changes what name 'foo' refers
to.  Unless overridden by a global statement, this also tells us
that barename 'foo' is local to this scope.  Because of this, Paul
would apparently like to call (part of) the effect of 'def',
'class', 'import', 'from' &c "assignment".  I disagree, as it seems
you do, but if Paul is keen to call "binding" the issue of the
previous paragraph, i.e. the establishment of a connection
between a name and a SCOPE rather than between a name and a VALUE,
I understand he'd be hungering for a term here.

I think calling 'assignment' the name-binding part of 'def', etc,
is horribly confusing and counterproductive.  But Paul can probably
point to languages where 'assignment' is used like that, rather
than (as in Python) to name a specific, DIFFERENT statement.  I'll
still disagree, given that most Python newbies which have some
other language experience are likely to think of "assighment" as
in that lexicon -- the "filling" of some kind of named box, the
"placing" into that box of a value.  "Scoping" or (as in C++)
"using" may be better names for 'connection of name and scope',
and we can keep saying 'binding' for 'connection of name and
value'.  Which probably won't make Paul happy, but...


> Consider namespaces as dictionaries. I *know* they aren't all implemented
> as dictionaries, but bear with me.
> You seem to be insisting that an operation is only a "binding" when the
> key (name) does not already exist in the dictionary (namespace). If the
> dictionary (namespace) already contains the key (name) then it's not a
> rebinding, it's an "assignment".

Rather, I think 'binding' in Paul's terminology is the operation of 
'determining WHICH dictionary this name is supposed to be a key into'.


Alex