On 12/28/05, Noam Raphael <[EMAIL PROTECTED]> wrote: > And another example: > > >>> a = 1+2j > >>> b = 2+1j > >>> a > b > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > TypeError: no ordering relation is defined for complex numbers > > I came to think that, when forgetting backwards compatibility for a > while, the best thing for comparison operators to do is to raise a > TypeError by default, and work only for types that it makes sense to > compare. I think it is more "explicit is better than implicit", and I > have now two reasons for that: > 1. Things like "Decimal(3.0) == 3.0" will make more sense (raise an > exception which explains that Decimals should not be compared to > floats, instead of returning false constantly). > 2. It is more forward compatible - when it is discovered that two > types can sensibly be compared, the comparison can be defined, without > changing an existing behaviour which doesn't raise an exception.
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. 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. -- Adam Olsen, aka Rhamphoryncus _______________________________________________ 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
