On Thu, 26 Apr 2012 18:02:31 +0200, Kiuhnm wrote: > On 4/26/2012 16:00, Adam Skutt wrote: >> C# and Python do have a misfeature: '==' is identity comparison only if >> operator== / __eq__ is not overloaded. Identity comparison and value >> comparison are disjoint operations, so it's entirely inappropriate to >> combine them. > > They're not "disjoint", in fact one almost always implies the other (*). > Python's idea is that, by default, any object is equal to itself and > only itself. The fact that this is equivalent to "identity comparison" > is just a coincidence, from a conceptual point of view.
Define your terms: what do you mean by "equal"? The complication is that "equal" has many meanings. Does 1/2 equal 2/4? Well, yes, numerically, but numerical equality is not the only useful sense of equality -- not even for mathematicians! Although the convention to write "1/2 = 2/4" is too strong to discard, there are areas of mathematics where 1/2 and 2/4 are not treated as equal regardless of numerical equality. http://en.wikipedia.org/wiki/Mediant_%28mathematics%29 In Python, "equal" can have any meaning we like, because we can override __eq__. For most meaningful equality comparisons, we expect that X should always equal itself, even if it doesn't equal anything else, and so __eq__ defaulting to an identity comparison if you don't override it makes good sense. Some people (e.g. the creator of Eiffel, Bertrand Meyer) argue that identity should *always* imply equality (reflexivity). I disagree, but regardless, reflexivity is *almost always* the right thing to do. When it comes to equality, Python defaults to sensible behaviour. By default, any object supports equality. By default, "a == a" is true for any object a. If you want to define a non-reflexive type, you have to do so yourself. If you want to define a type that doesn't support equality at all, you have to do so yourself. But both use-cases are vanishingly rare, and rather troublesome to use. It would be stupid for Python to make them the default behaviour. After all, Python is a tool, not a philosophy. There's no need to force the user to start from a blank slate and define everything from first principles when you can start with the common tools you normally need, and add or subtract from it as needed. > (*) nan == nan is false, but, at least conceptually, a 'NotComparable' > exception should be raised instead. That wouldn't be very useful, > though. NANs are comparable. By definition, NAN != x for every x. They're just not reflexive. >> I don't necessarily mind if the two operations have the same symbol, as >> long as there's some other way in-context to determine which operation >> is occurring. This is the case in C and C++, for example. >> >>> Python's way is much much cleaner. >> >> Nope. Automatically substituting identity equality for value equality >> is wrong. While rare, there are legitimate reasons for the former to >> be True while the latter is False. > > There shouldn't be, to be fair. I disagree. Violating reflexivity has its uses. NANs are the classic example. Another example is if you redefine "==" to mean something other than "equals". If your class treats == as something other than equality, there is no need for a==a to necessarily return True. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
