Python 3.0, rich comparisons and sorting order

[Steven Bethard]

On Tue, 21 Sep 2004 15:07:30 -0300, Carlos Ribeiro <carribeiro at gmail.com> wrote:
> Assume that you're implementing a spreadsheet like application in
> Python. The user fills a column with arbitrary data, and asks for it
> to be sorted. What is the sorting order? Excel, for instance, defines
> an ordering (it's arbitrary, but it's deterministic).

Thanks, that helps.  You can always have end users asking you to sort
things that shouldn't be sorted...

Presumably you could change how sort works so that it first stratifies
the list by type, and then sorts for each type.  The types would then
be ordered arbitrarily (perhaps by the id of their type?)...  Might
slow down the normal-case sort though...

Hmm...

> The set, in this particular case,
> is a Python list, that *can* contain arbitrary data. So it does not
> make sense (in my not-so-humble opinion) for sort to impose
> restrictions based on the list element type.

Yeah, by restricting comparisons, we'd be basically saying that sort
is only defined for lists that take the form list<some_type>.

> (BTW, if we extend this reasoning, the same could be said for other
> types of functions that work over sets -- sum() should ignore
> non-numeric values, etc. But that's another philosophical battle)

Currently sum is only defined for iterable<number_type>.  Of course
the vast majority of Python functions have type restrictions on their
arguments (and will raise TypeErrors if these are violated).  So I
suspect we don't have to fall down the slippery slope and make all
functions fully generic.

Steve
-- 
You can wordify anything if you just verb it.
        - Bucky Katt, Get Fuzzy