[Tutor] <var:data> assignment

[Alan Gauld]

Hi Denis,

Some quite profound things here, slightly confused because you
have happened to stumble on some special optimisations in
Python for your examples!

> data. Then, Python must draw a kind of name --> value mapping to
recover it
> when needed, let's call that 'registration'. This is of course, you
have
> noted it ;-) the structure of a Python dictionary:

Indeed, almost everything in Python is implemented upon dictionaries.

> Now, this doesn't mean that in the language's blackbox (in C),
variable
> registration is really implemented as a dictionary.

But in fact it is.

> Third, conversely, when a value changes, its place changes, too.

Not quite. When a value changes a new value is stored in its place.
The old value is lost. Or at least it is for immutable types such
as the numbers and strings that you are using.

For mutable types such as lists the pictire changes.

> All of this leads (me) to question the above dictionary-like model.
It seems
> that, instead of values, the id-s are bound to variable names.

No, in these cases they are bound to addresses as you point out later.
There are no names involved, either in Python or even in C.

> Python. In python, we could eventually see variables as labeled
boxes
> holding adresses, pointing to data ; while the data would be
unlabeled
> boxes holding values:

Absolutely correct, and the variables therefore are the labels. That
is variable names in Python are just that names. Names used as keys
in a dictionary and the values are the addresses of the data objects.

> Now, consider the case of compound data:
>
> >>> l1=[1,2]
> >>> l2=[1,2]
> >>> l1 == l2, l1 is l2
> (True, False)
>
> This contredicts the first rule saying that if a data exists, it
needs not
> beeing created again. l1 and l2 hold the same data --there're
equal--,
> but not at the same place --they're not identical

Correct because lists are not immutable. Python has a clear
distinction
in the way it handles mutable and imutable data.

> We can explain this (at first sight) strange behaviour by
recursively
> applying the other rule, the one saying that a variable isn't bound
to a
> value, but to an address instead.

Correct, the address of the list in this case.

> >>> l1=[1]
> >>> l2=[1]
> >>> l1 is l2
> False

Which is as you would expect since the two lists are different
although
they hold references to the same object

l1 -> [] -> 1
            ^
            |
l2 -> [] ---+

> >>> l1=l2=[1]
> >>> l1 is l2
> True

Because they point to the same list

l1 -> [] -> 1
       ^
       |
l2 ----+

> >>> l1=[1]; l2=[1]
> >>> l1 is l2
> False

Exactly the same as the first example

> >>> l1=l2
> >>> l1 is l2
> True

Exactly the same as the second example except that the list doesn't
contain any data. BTW This is all explained in the Python Language
Reference albeit in fairly technical words... And if you read C you
can always read the source! :-)

Alan G.