At the risk of boring the other readers.... Yes. You are right. But so was I (on the second time around):
a=1 b=1 a and b could refer to the same object or different objects with the same value. It depends on implementation details. I agree here. a=1 b=a a and b refer to the *same* object here regardless of implementation. Massimo said they were different, because b+= 2 doesn't change a. That statement is incorrect. That's really all I was trying to say. I wasn't trying to be philsophical about Platonic singleness in the universe or whatever. Cheers, Carl. On 29 March 2011 13:02, Laura Creighton <l...@openend.se> wrote: > In a message of Tue, 29 Mar 2011 11:49:08 +1300, Carl Cerecke writes: > >--20cf307abcff67e7bc049f92c049 > >Content-Type: text/plain; charset=ISO-8859-1 > > > >Yes. Laura, you're correct. I'll try again: > > > >Massimo was trying to say that after: > >a = 1 > >b = a > > > >b and a refer to *different* 'one's because changing one of them (b += 2) > >doesn't change the other. > > > >This isn't true. They refer to the same 'one' object (regardless of pytho > >n > >implementation). b += 2 doesn't change the 'one' object, but simply point > >s b > >to a 'three' object. > > > >There. How's that? > > > >Carl. > > Incorrect, I think. When I am talking about 'the same 'one' object', > what I mean is not some sort of philosophical one-ness, some Platonic > ideal of one, which like all the numbers, is a singleton, wherever it > occurs in the universe. I mean something much more concrete than > that. Somewhere in my computer are addressable pieces of memory, and > in those locations are values. When I say that two variables are > bound to the same object I mean they refer to that exact same piece of > memory right there. (We will ignore, for the purpose of this > discussion, issues related to garbage collectors that move objects > around. Because its the job of the gc writer to make sure that after > the collection happens, all of those references to the old memory > location all point to the new memory location. So the location is > different, but the property that all variables bound to the same object > get the same location in memory remains true.) > > Consider what happens when your memory goes bad. Stray alpha particle, or > (more likely) just a bad bit of memory. > > I've typed: > > >>> w = 1 > >>> y = 1 > >>> z = 1 > > suddenly, a bit of memory goes bad, the chunk that w is bound to. Instead > of containing 1, it contains 2. > > What happens? > Well, in CPython, w is now bound to the value 2. So is y and z. And > I will bet that CPython will fall over and die a horrible death. All > the places where it internally uses the value '1' will get the wrong > value. But this is an implementation detail. > > But in PyPy, when the chunk that w is bound to goes bad, y and z, which > were bound to entirely different pieces of memory, still have good values > in them. Assuming that w is not something that PyPy uses internally, it > is entirely possible that things could go on seemingly fine. Should w > be in the code you typed at an interactive PyPy interpreter, you may be > amazed and perplexed when you type: > > >>>> w = 1 # that memory location goes bad right now! > >>>> w + w > 4 > > Not the result you expected. You'd complain pypy was broken, and if > it kept happening (i.e. it was a bug, not bad memory) you'd be correct. > > --------------- > What I think you are trying to say is that you cannot change the values of > immutable objects. Which is very true. (Barring disasters with bad memory > and alpha particles and the like.) But this has nothing to do with how > many immutable objects share the same value. It has to do with the fact > that you cannot mutate immutable objects. > > >>>> a = 1 > >>>> a = 2 > >>>> a = "horseradish" > > All I have done is changed a's bindings. No walking out to memory, making > a > chunk of it mean '1', and binding a to it, then walking about again, > finding > the same bit of memory, and scribbling on it so it means '2', and then > walking out and scribbling on it to mean 'horseradish'. That doesn't > happen. > > as opposed to: > > >>>> a = [1] > >>>> b = a > >>>> a.append(2) > >>>> b > [1, 2] > > a.append(2) really did walk out into memory, find the bit that a was bound > to, and scribbled on it so that where it once said [1] it now says [1, 2] > Since b is bound to the same bit of memory, it changes too. > > Laura > > > > > > >
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
