On Sat, 14 Jan 2006 18:26:41 -0500, Mike Meyer wrote: > If two objects ARE the same value, then they should be the same > object.
You are assuming that values are unique, and that therefore is X "is" (in the English sense, not the Python sense) some value, then no other thing Y can also be the same value. I simply reject that interpretation: I see nothing wrong with allowing two or more objects to be distinct objects and yet be the same value. Two physical copies of the same book "are the same" (are equal) if they have the same words in the same order in the same typeface on the same kind of paper, even if they came out of different printing presses on different days. I don't claim that the same many-to-many relationship between value and object *must* hold, in either real life or Python, merely that it *can and sometimes does* hold. e.g. Borg instances all have the same value, even though they have different identity. NaN floats are supposed to compare unequal even with themselves. This may even be an implementation detail: >>> 1+1 is 2 True >>> 1000+1000 is 2000 False Since the 2000 on the left has different identity from the 2000 on the right, do you wish to argue they have different values? I imagine not. Neither would I. I also will comfortably use the term "the object has the value foo" when I wish to distinguish between object and value, or when the object is mutable, or just whenever I feel like it. I don't think it usually matters whether we talk about the int 1 "being 1" or the int 1 "having the value 1". Where it does matter is for abstract types like object(), because they don't have any "concrete" value *other than their own internal state*. I put "concrete" in scare quotes because I'm fully aware that numbers like 1, 4.6, or strings like "mary had a little lamb" are in fact abstract, not concrete. One sheep is a concrete thing, one is abstract. But nonetheless, we behave as if 1 was a concrete thing. I'm also fully aware that the 1-ness that distinguishes the int 1 from the int 2 is part of the object's internal state too. I don't mean to imply that non-abstract classes like int must have something (what? who knows?) over and above their own internal state. What I mean is that we humans have a concept of (numbers) 1 and 2, and we can map the number 1 to the int 1 to the byte 00000001. We have no such simple concept to make abstract objects to. > In particular, if the value is mutable, and you > change one object that is some value you change the value, but the any > other objects that are that value are still the old value of the value > (um, I hope you know what I mena). Something like this perhaps? L = [1, 2, 3] M = [1, 2, 3] L is M ==> False L == M ==> True L.append(4) L == M ==> False I have no problem with that. Some objects are mutable and can change their value, some are not. That's no different from having a byte in memory, and flipping bits. It is the same *byte*, even though the value it has changes. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
