why cannot assign to function call

[Aaron Brady]

On Jan 6, 8:03 am, Mark Wooding <m... at distorted.org.uk> wrote:
> Steven D'Aprano <st... at 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.