[Python-Dev] Keep default comparisons - or add a second set? (original) (raw)

Noam Raphael noamraph at gmail.com
Wed Dec 28 16:13:44 CET 2005

On 12/28/05, Adam Olsen <rhamph at gmail.com> wrote:

I agree for greaterthan and lessthan operators but I'm not convinced for equality. Consider this in contrast to your example: >>> a = 1+2j >>> b = 1+2j >>> a is b False >>> a == b True

Complex numbers can't be sorted but they can be tested for equality. Decimal numbers can't currently be tested for equality against a float but there's no loss-of-accuracy argument to prevent it (just a difficulty of implementation one.) If the comparison is to fail I would prefer an exception rather than an id-based fallback though.

I think we agree. I don't think that every type that supports equality comparison should support order comparison. I think that if there's no meaningful comparison (whether equality or order), an exception should be raised.

Speaking of id, there's no reason why "id(a) == id(b)" has to fail for mismatched types in the face of persistence so long as the result of id() has the same lifetime as the target object. This could be done using weakrefs or by making an id type with a strong reference to the target object.

I don't mean to change the current behaviour of id() - I just meant that an additional one may be implemented, possible by a specific library (Zope, for instance), so the built-in one shouldn't be used as a fallback default.

Noam

More information about the Python-Dev mailing list