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

Adal Chiriliuc adal.chiriliuc at gmail.com
Wed Dec 28 15:02:08 CET 2005

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.

More information about the Python-Dev mailing list