On Nov 15, 12:51 am, Steven D'Aprano <[EMAIL PROTECTED] cybersource.com.au> wrote: > On Fri, 14 Nov 2008 22:56:52 -0500, Terry Reedy wrote: snip > I would say that the answer to this is, "Would you like to include > behaviour in value?". Let me give you an example: > > class String(string): > def upper(self): > return "spam" > > s1 = "Norwegian Blue" > s2 = String("Norwegian Blue") > > Do s1 and s2 have the same value? > > Using definition (1) above, we can see that the names s1 and s2 refer to > different objects, so the names have different values. > > Using definition (2), the objects s1 and s2 have different concrete > expressions, and so they are different values. (Remember: the object is > the value.) But from definition (3) they both represent that same > abstract string, so if I care only about that level of description, I'd > say yes they *have* the same value but *are* different values. > > Assuming I cared about the behaviour of upper(), then s2 is probably not > suitable for my purposes and so I would like to distinguish s1 from s2. > I'd insist that they have different values which merely looked the same > under equality. To use the bank note analogy, then s1 is legal tender but > s2 is just a very good forgery. > > But note that to a collector of forgeries, s2 might be more valuable than > s1, and presumably the writer of class String had a reason for the > behaviour given. The answer to the question "do s1 and s2 have different > values" will depend on why you are asking. > snip > I would say that although value is dependent on context, that's no excuse > for concluding that it has no meaning. If you look too closely at > *anything*, it becomes fuzzy. (Well, with the possible exception of pure > mathematics.) > > -- > Steven
I'm reading that the result of the __eq__ comparison isn't the only meaning of value, and that there is more than one. >>> class String(str): ... def upper(self): ... return "spam" ... >>> s1 = "Norwegian Blue" >>> s2 = String("Norwegian Blue") >>> s1== s2 True >>> s1.upper()== s2.upper() False Murmur, good. I could see rejecting that two objects of different types can have the same value. I could also see rejecting that 'the value than an object is' is nonsense, permitting only 'the value that an object has'. However, as a counterexample, 'x has the value [1, 2, 3]' and 'x is [1, 2, 3]' are both colloquially sensical statements, though the latter is imprecise, because 'x is [1, 2, 3], y is [1, 2, 3], x is not y'; certainly '[1, 2, 3]' is neither 'x' nor 'y', and identity is a commutative relation. If you'll permit a tangent into another (computer) language, I don't have a problem saying either that the value of x in 'int* x' in C is a memory address, or that its value is an integer, which stance is definitely prone to miscommunication. I still maintain that passing an object by value calls its copy constructor. -- http://mail.python.org/mailman/listinfo/python-list