Python 3.0, rich comparisons and sorting order

Carlos Ribeiro carribeiro at gmail.com
Tue Sep 21 16:54:38 EDT 2004


On Tue, 21 Sep 2004 20:04:07 GMT, Andrew Dalke <adalke at mindspring.com> wrote:
> Phil Frost wrote:
> > The right question here is, "is there a reason for mappings with
> > heterogeneous key types?" It's not something that I do often, but it's
> > something that's important to have. Dynamic typing is a good thing.
> 
> Though it's a different question.  mapping keys only
> need to define __hash__ and __eq__.  That's easier than
> defining an ordering.

Given all the arguments, I'm changing my approach to the sorting
problem. My proposal is that sortable objects should provide a __key__
method. sort() already accepts a key function to be passed. As of
today, there are 4 different ways to customize sorting behavior:

1) passing a comparison function to sort();
2) passing a key generation function to sort();
3) implementing __cmp__;
4) implementing rich comparison methods. 

If the current sorting behavior is to be changed -- as proposed for
Py3K --, I think that relying on methods such as (3) and (4) is not a
good idea; __cmp__ is already on the way to deprecation, and rich
comparisons are already being extended for other uses that have
nothing to do with sorting. I think that a __key__ function is better
than (2) (it looks more pythonic to me). Alternative (1) -- the
comparison function -- may still be useful for some situations, but
it's not needed if __key__ is implemented.

(BTW -- in Py3K, __key__ could be used to generate the hash value for
objects that don't suply a __hash__  method. -- but that's another
idea, just for the record)

In my proposal, __key__can assume one of the following values:

1) None
2) Boolean (True or False)
3) Number (int or float)
4) String (Unicode, of course -- that's another beast to sort properly)
5) Sequence (list or tuple) composed of the types listed here

The ordering would be the same presented in the list above -- None is
the smallest value possible, then booleans, numbers, and so on. It's a
reasonable ordering, for most possible applications. It doesn't
attempt to guess at overly complex values or data structures.

There is at least one case that it's not so complex, it's relatively
common, and it's properly handled by today's sort() and by the
proposal above. If you retrieve a list of values from a database, some
rows may contain null values (mapped to None). If you try to sort them
in Py3K, you're out of luck, unless you provide an alternative sorting
method. That's not necessary, in my opinion.

It's a simple proposal. What do you think?


-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro at gmail.com
mail: carribeiro at yahoo.com



More information about the Python-list mailing list