wasm-demo/demo/ermis-f/python_m/cur/0153

101 lines
3.4 KiB
Plaintext

From: faassen at pop.vet.uu.nl (Martijn Faassen)
Date: Tue, 27 Apr 1999 18:29:32 +0200
Subject: Pointers to variables
References: <19990422121403.A279051@vislab.epa.gov> <371F6124.48EA9794@pop.vet.uu.nl> <7g2f5m$kl6$1@mlv.mit.edu>
Message-ID: <3725E5EC.63AC65B1@pop.vet.uu.nl>
Content-Length: 3156
X-UID: 153
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