On 2010-12-07 16:09:17 -0800, Mark Wooding said:
Carl Banks <pavlovevide...@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
--
http://mail.python.org/mailman/listinfo/python-list
