Pointers to variables

Martijn Faassen faassen at pop.vet.uu.nl
Tue Apr 27 12:29:32 EDT 1999


Michael Vezie wrote:
> 
> In article <371F6124.48EA9794 at pop.vet.uu.nl>,
> Martijn Faassen  <M.Faassen at vet.uu.nl> wrote:
[snip my code example]
> 
> I don't think it has anything to do with mutable or not.  mylist[0]
> simply points (at first) to the same object (string) that
> variable_i_want_to_change (hereafter called 'var2chg').  Then,
> at the second assignment, mylist[0] points to something different.
> If var2chg were an array or dictionary, it would make no difference;
> mylist[0] would still, after the second assignment, be "Bar".

I know this; I probably made it sound too horribly complicated.

> >    mylist = [None]
> >    variable_i_want_to_change = {}
> >    mylist[0] = variable_i_want_to_change
> >    mylist[0]["some key"] = "bar" # indeed changes
> >variable_i_want_to_change!
> 
> This is different from the other examples.  Here, you dereference
> mylist[0] (which is still pointing to the same object that var2chg
> points to).  So the common object that they both point to changes.
> Strictly speaking, you aren't changing var2chg, just that which it
> (and mylist[0]) points to.

Yes, that's because everything in Python is a reference. But in case of
immutable objects this is identical to value semantics, unless you use a
tuple which contains a mutable object in itself.
 
> >    # mylist[0] = "Bar" -- doesn't work, makes mylist[0] point elsewhere
> 
> Well, it works as expected.  It changes mylist[0], not what mylist[0]
> references.

If you know you're dealing with references and that assignment only
changes what variable references what data, yes. I was attempting to
explain the implications of this, but I admit it was horribly
convoluted. :)
 
[snip my atrocious C code]
 
> I wonder if this is how it goes.  I've not dived into the python
> engine code, so I don't know.  Are immutable objects stored as
> objects or just as the data?  

I haven't dived in the Python code either, but I've seen people talk
about Python allocating an object for either integer, so I imagine yes.

> In the grand scheme of things, it
> really makes no difference.  If there were an "add" method for
> ints (so you could say:
> 
>         var2chg = 5
>         var2chg.add(3)
>
> and have var2chg have a value of 8), then it would obviously be
> a concern.  But you can't, so it really doesn't matter at the
> python level whether:
> 
>         a = 5
>         b = a
> 
> means that b and a point to the same object, or to separate
> values of 5.  If you could do b.add(3) and suddenly have a
> with a value of 8, then it would.

Yes, unless you deal with tuples, which are immutable, but can contain
mutable things:

a = { "mutable" : "Yes" }
b = (a, "foo")
c = b
c["mutable"] = "really"
# b is changed at this point too, even though the tuple was immutable

This was pointed out to me on the Python tutor list after I pointed out
that reference vs value semantics is the same in case of immutable
objects. It's only the same in case they're deeply immutable (or if you
exclude tuples).

Anyway, I was trying to attempt to explain the same principles as you
did; I just wasn't very succesful at it. :)

Regards,

Martijn




More information about the Python-list mailing list