On Jan 6, 8:03 am, Mark Wooding <m...@distorted.org.uk> wrote:
> Steven D'Aprano <st...@remove-this-cybersource.com.au> wrote:
snip
> > It seems that you don't include in the Python community all those who
> > use the term "name binding" instead of variable assignment
> > specifically because it gives new users a clue that Python is not the
> > same as C.
>
> Unfortunately, this practice causes other confusion, since `binding' is
> often used (in other language communities, notably Lisp and the
> functional languages) to describe the association between names and
> slots that hold references.
>
> Let me explain. I'll try to be clear, though I know that Stephen
> already understands this stuff well.
>
> At run-time, each named variable denotes a storage area (I'll call it a
> slot[2]) which holds a reference to some object[1].
>
> +-----+
> name ----> | ref -----> object
> +-----+
>
> If we `assign' a different object to the variable, what really happens
> is that the slot is modified to refer to the other object; but the name
> continues to denote the same slot.
>
> Usually `binding', or `rebinding', a name describes a different process,
> whereby the name (for a while) denotes a different slot. This name-to-
> slot mapping is important because it's the mapping which is inherited by
> nested functions.
Say you start with:
+------+
a ----> | ref1 -----> (1, 2, 3)
+------+
Then you can do:
+------+
a ----> | ref2 -----> (4, 5, 6)
+------+
But not:
+------+
a ----> | ref1 -----> (4, 5, 6)
+------+
That is, you can 'repoint a' to another 'ref', but not repoint a
'ref'.
I think one of the ideas we have trouble communicating is that [1, 2,
3] and [4, 5, 6] can be the same object (using '[:]='), but [1, 2, 3]
and [1, 2, 3] don't have to be.
--
http://mail.python.org/mailman/listinfo/python-list
