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

[Adal Chiriliuc]

On Wednesday, December 28, 2005 Noam Raphael wrote:
> 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.

Here's what happens if you try to compare a string and an int in .NET
(it's a compiler error):
error CS0019: Operator '<' cannot be applied to operands of type 'string' and 'int'
error CS0019: Operator '==' cannot be applied to operands of type 'string' and 'int'

Of course, C# is not a dynamic language so things are stricter in
general.

Maybe having == and != work for whatever combination of types is not
such a bad thing. After all, 10 != "text", but then what about Decimal(3.0)
== 3.0?

It doesn't make sense to say that a function object is smaller or
bigger than a string.

And if you sort a list of different objects based on theirs address or
something similar, can you really consider that list sorted? If you
want to normalize a list, you can sort it by using id(item) as a key
and not rely on default comparasions.