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
