On 12/28/05, Adam Olsen <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
