[Tutor] Re: references, mutability, dictionaries, etc.

[Magnus Lycka]

At 14:22 2002-11-26 +0100, Charlie Clark wrote:
>I got bitten by this last night: when is an object an object not a
>reference. I found I was automagically updating the REQUEST object in Zope
>without wanting to do this at all. It's the sort of thing coloured syntax
>would be nice for.

An object is always an object. A variable is a name for (or if you prefer)
a reference to, an object. Always! No ambiguities really. It's much more
simple and consistent than in C++ for instance. There are no pointers to
pointers and there is no distinction between integers, pointers to integers
or references to integers in Python. All variables are references to any
kind of object, and every assignment "a = b" means that 'a' will be a
reference to the same object as 'b' is a reference to. If you do "a = b",
both 'a' and 'b' will refer to the same object until either 'a' or 'b' is
reassigned to something else. Isn't that simple?

So, when you do:

a = 5
b = a
print b

or

def x(b):
   print b

a = 5
x(a)

you will have two variables 'a' and 'b' that both refer to
the the same object. (Although in the second example, they
are in different scopes.)

In these cases, you can't change the content of what "a" refers
to by changing what "b" refers to, because of the simple fact
that an integer object can't ever be changed. 5 is 5 is 5 and
will so ever be. Integers are immutable. There is no way you
can turn a five into a 6 or a 0 etc. If you do something like
a = a + 1, it means that 'a' won't point to the same object any
longer, but rather to another integer object: 6. (You can use the
builtin function id() to examine whether or not objects are the
same. id returns a location in memory for a particular object.

a = <something> is an assignment. It means that 'a' ceases to
refer to whatever it refered to before, and starts to refer
to something else. 'b' still refers to what it always refered
to unless you reassign 'b' with 'b = <something>'. Now, there
are reassignments that don't quite look like this, for instance
'a += 1' or 'b *= 2'. Guido was rather reluctant to include those
in Python and I think the reason was that he felt that it might
not be completely obvious in these cases that the variable was
rebound. But it is!

If you use a mutable object, reassignment still works the same.

a = [1, 2]
b = a

The variables 'a' and 'b' now point at the same object, but
if you do.

b = b * 2

they will no longer point to the same. You are creating a new
list containing [1,2,1,2] (this is the only thing the expression
"b * 2" can ever do) and you are assigning 'b' to point at that
new list object.

On the other hand, if you would do

b.extend(b)

instead, you've NOT reassigned b. You have modified the
list object that both 'a' and 'b' points to. In other words,

if
a = b = [1,2]

then 'a.append(1)' means "append 1 to the end of the list that
the variable 'a' refers to". It's identical with 'b.appned(1)'

and 'a[-1] = 2' means "The variable 'a' refers to a list object.
Change the last location in this list object into a reference to
the integer 2, istead of whathever it refered to before." So, it's
identical with 'b[-1] = 2'

On the other hand, 'a = a + [3,4]' means "Create a new list object
which consists of the list object that the variable 'a'(still) refers
to concatenated with the list object [3, 4]. Then reassign the
variable 'a' so that it points to this new list object. In other words,
it's identical with 'a = b + [3,4]' but NOT with 'b = a + [3,4]'. In
this last statement, it's the variable 'b' that is rebound, not 'a'
as in the two previous.

You see? 'a += 1' is fundamentally different from 'a.append(1)'.
'a += 1' changes the VARIABLE 'a'. 'a.append(1)' changes the OBJECT
that 'a' refers to!

When we work with immutable objects, there is no problem. Obviously,
we can't accidentally change an immutable object. There might be a
problem when we work with mutable objects if we faill to see when we
need to copy an object before we change it, because we need to keep
the unchanged object as well.

We might also have problems if we don't know how to create copies of
an object. Obviously, simple assignments never copies objects, they
just add references to them. Object copying must be done in some
other way...


-- 
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/  mailto:magnus@thinkware.se