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 python implementation). b += 2 doesn't change the 'one' object, but simply points b to a 'three' object. There. How's that? Carl. On 29 March 2011 10:25, Laura Creighton <l...@openend.se> wrote: > In a message of Tue, 29 Mar 2011 09:59:40 +1300, Carl Cerecke writes: > >Well, not really. Although I see what you are trying to say. > > >numbers (like strings) are immutable. There can ever be only one number 1 > >You can't change a number to something else. If add 5 to 3, the number 3 > >doesn't change, I get a new number, 8. > > This is merely an implementation detail. > > Python 2.6.6 > Type "help", "copyright", "credits" or "license" for more information. > >>> w = 1 > >>> y = 1 > >>> w is y # this might surprise you > True > > [PyPy 1.4.1] > Type "help", "copyright", "credits" or "license" for more information. > > >>>> w = 1 > >>>> y = 1 > >>>> w is y # or are you so used to CPython that this surprises you? > False > > You can have as many number ones as you like. In CPython they are > cached to be the same object, but you shouldn't rely on that behaviour. > It's actually pretty dodgy to test the object identity on immutable > objects -- unless you want to surprise people like I tried to. > > Incidentally > > Python 2.6.6 > Type "help", "copyright", "credits" or "license" for more information. > >>> w = 5234 > >>> y = 5324 > >>> w is y > False > > so after a certain point, the CPython developers have decided that the > performance gains of cacheing all number xs as the same x isn't worth > it. > > Laura > > >
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
