[Python-Dev] Keep default comparisons - or add a second set?

[Noam Raphael]

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