On 5 May 2006 05:23:24 -0700 in comp.lang.python, "vdrab" <[EMAIL PROTECTED]> wrote:
>> Are you telling us that you *had* read that doc, >> and tripped because it says "depending on the implementation", >> when it should say "at the choice of the implementation" ? > >no. >let's see, where to start ... ? >let's say there's a certain property P, for the sake of this loooong >discussion, something >more or less like a class or type's property of "having immutable >values, such that any instance with value X has a single, unique >representation in memory and any two instantiations of objects with >that value X are in fact references to the same object". IOW, property P is "(x == y) => (x is y)" (read "=>" as "implies"). Note that only immutable objects can have property P. > >Then, for example, python strings have property P whereas python lists >do not: > >>>> x = "test" >>>> y = "test" >>>> x is y >True >>>> x = [] >>>> y = [] >>>> x is y >False >>>> Note this last relationship is _guaranteed_. Lists are not immutable, and therefore can not have property P. > >Now, as it turns out, whether or not python integers have property P >_depends_on_their_value_. >From the zen, I believe this falls out from "practicality beats purity." >For small values, they do. For large values they don't. Yes, I Even that's not necessarily true. The implementation is free to always create a new immutable object, even for small values. >understand about the interpreter optimization. I didn't know this, and >I find it neither evident nor consistent. I don't think the above post >explains this, regardless of how you read "implementation". Think about implementation for a moment. Consider the statement x = some_arbitrary_integer() Do you really want the interpreter to go through all the existing integer objects in the program to see if that particular value exists, just to guarantee some some later statement x is y returns True if x == y? OK, maybe we can change the "is" operator on immutable objects such that x is y returns True if x == y. But then you can encounter a situation where "x is y" but "id(x) != id(y)" Now what? Perhaps the solution would be to disable the "is" operator and "id" function for immutable objects. But then _they_ lose generality. There doesn't seem to be a way to win. So it all comes down to "who cares?" Immutable objects are immutable. You can't change them. Object identity is a non-issue. This is not the case for mutable objects. Consider a = [1,2,3] b = [1,2,3] c = a a==b a==c b==c a is not b b is not c c is a c.append(4) > >In fact, the whole string of replies after my initial question reminded >me of something I read not too long ago, but didn't quite understand at >the time. >source : >http://www.oreillynet.com/ruby/blog/2006/01/a_little_antiantihype.html > [...whinge elided...] > >taking this rant with the proverbial grain of salt, I did think it was >funny. Your original post in its entirety (ignoring the example) was "what the...? does anybody else get mighty uncomfortable about this? " The first response (paraphrased) was "No. Why should I? With immutable objects, I care about ==, not is." Your response seemed to want to cast doubt on the integrity of the entire language: "Given this though, what other such beauties are lurking in the interpreter, under the name of 'implementation accidents'?" > >Anyway, thanks for all the attempts to show me. >I will get it in the end. I will ignore the double entendre, and simply hope I was of help, and wish you luck. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list