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. _______________________________________________ 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