Comparisons of incompatible types

[TomF]

On 2010-12-07 16:09:17 -0800, Mark Wooding said:

> Carl Banks <pavlovevidence at gmail.com> writes:
> 
>> I think that feeling the need to sort non-homogenous lists is
>> indictative of bad design.
> 
> Here's a reason you might want to.
> 
> You're given an object, and you want to compute a hash of it.  (Maybe
> you want to see whether someone else's object is the same as yours, but
> don't want to disclose the actual object, say.)  To hash it, you'll need
> to serialize it somehow.  But here's a problem: objects like
> dictionaries and sets don't impose an ordering on their elements.  For
> example, the set { 1, 'two' } is the same as the set { 'two', 1 } -- but
> iterating the two might well yield the elements in a different order.
> (The internal details of a hash table tend to reflect the history of
> operations on the hash table as well as its current contents.)
> 
> The obvious answer is to apply a canonical ordering to unordered objects
> like sets and dictionaries.  A set can be serialized with its elements
> in ascending order; a dictionary can be serialized as key/value pairs
> with the keys in ascending order.  But to do this, you need an
> (arbitrary, total) order on all objects which might be set elements or
> dictionary keys.  The order also needs to be dependent only on the
> objects' serializable values, and not on any incidental facts such as
> memory addresses or whatever.

I have no argument that there might be an extra-logical use for such an 
ordering which you might find convenient.  This is the point you're 
making.  sort() and sorted() both take a cmp argument for this sort of 
thing.   My complaint is with Python adopting nonsensical semantics 
("shoe" < 7) to accomodate it.

By analogy, I often find it convenient to have division by zero return 
0 to the caller for use in calculations.  But if Python defined 0/0==0 
I'd consider it broken.

-Tom