Andreas Maier writes: > The problem of the default implementation is that "x is not y" > implies "x != y" and that may or may not be true under a sensible > definition of equality.
I noticed this a long time ago and just decided it was covered by "consenting adults". That is, if the "sensible definition" of x == y is such that it can be true simultaneously with x != y, it's the programmer's responsibility to notice that, and to provide an implementation. But there's no issue that lack of an explicit implementation of comparison causes a program to have ambiguous meaning. I also consider that for "every object has a value" to make sense as a description of Python, that value must be representable by an object. The obvious default representation for the value of any object is the object itself! Now, for this purpose you don't need a "canonical representation" of an object's value. In particular, equality comparisons need not explicitly construct a representative object. Some do, some don't, I would suppose. For example, in comparing an integer with a float, I would convert the integer to float and compare, but in comparing float and complex I would check the complex for x.im == 0.0, and if true, return the value of x.re == y. I'm not sure how you interpret "value" to find the behavior of Python (the default comparison) problematic. I suspect you'd have a hard time coming up with an interpretation consistent with Python's object orientation. That said, it's probably worth documenting, but I don't know how much of the above should be introduced into the documentation. Steve _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
