strange behavor....

[Arnaud Delobelle]

mdw at distorted.org.uk (Mark Wooding) writes:

> Assignment /never/ binds.  There is syntactic confusion here too,
> since Python interprets a simple assignment in a function body -- in
> the absence of a declaration such as `global' to the contrary -- as
> indicating that the variable in question should be bound to a fresh
> variable on entry to the function.  But assignment itself doesn't
> perform binding.  (This is a persistent error in the Python community;
> or, less charitably, the Python community gratuitously uses the word
> in a different sense from the wider programming-language-theory
> community.  See Lisp literature passim, for example.)
>
> There's a two step mapping: names -> storage locations -> values.
> Binding affects the left hand part of the mapping; assignment affects
> the right hand part.

I'm not sure the notion of "storage location" is useful in Python. I
think I understand Python programs correctly using only the notions of
"name" and "value" (or object).

After execution of the statement:

    a = 1

The name "a" is bound to the object 1, which means that from then on "a"
evaluates to 1.  There is no need to know more.

As you point out, statements like:

    a[3] = 1
    a.b = 1

are different because they are really function calls, i.e.

    a.__setitem__(3, 1)
    a.__setattr__("b", 1)

so there is not necessarily any "assigning" or "binding" involved.  It
is simply a widely followed convention that after the function call:

    a.__setitem__(3, 1)

the function call:
    
    a.__getitem__(3)

should return 1.

Augmented assignment is a different kettle of fish altogether, and IMHO
it is the one that confuses things a lot.

-- 
Arnaud