Comparisons of incompatible types

Robert Kern robert.kern at gmail.com
Mon Dec 6 12:46:21 EST 2010


On 12/6/10 11:16 AM, TomF wrote:
>
> On 2010-12-06 09:04:00 -0800, Peter Otten said:

>> This change would break a lot of code, so it could not be made within the
>> 2.x series. However:
>>
>> Python 3.1.1+ (r311:74480, Nov 2 2009, 15:45:00)
>> [GCC 4.4.1] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>> "4" < 7
>> Traceback (most recent call last):
>> File "<stdin>", line 1, in <module>
>> TypeError: unorderable types: str() < int()
>
> Thanks. I was hoping there was something I could do for 2.x but I suppose this
> will have to do.
>
> But I'm mystified by your statement, "this change would break a lot of code".
> Given that the semantics are virtually random, how could code depend on this?

There are cases where you don't particularly care *what* order is given as long 
as it is consistent. Let's say you want to make sure that two lists have the 
same contents (which may mix types), but you don't care about the order. You 
could just sort each list and then compare the sorted lists. Before sets were 
added to the language, this was a fairly common approach.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco




More information about the Python-list mailing list