can't sort

[Tim Peters]

[Anders J. Munch]
>> This particular code.  There's some talk though about switching to
>> less-than predicates instead of -1,0,1 compares in future Pythons, so
>> I'd have take that into account before nominating anything my final
>> candidate.

[andrew cooke]
> are you following python-dev?  i thought something like that was
> squashed fairly recently (koenig or ewing made the suggestion, and it
> looked like guido didn't understand it, but then it appeared he did,
> but then he squashed the idea anyway, iirc...)

Andrew Koenig suggested that sort could accept a comparison function that
returned either -1/0/1 or True-on-less-than, and sort could guess which kind
it was by magic.  That specific suggestion didn't get over.  The idea of
allowing some way to explicitly specify that comparison was to be done via a
True-on-less-than predicate was liked.

> ...
> if i were you i'd post to python-dev and ask (although it's probably a
> bad sign that tim peters hasn't posted on this thread already), but i
> get the impression that timing is everything there.  maybe you want to
> wait until there's a heady surge of new feature accepting (last time i
> looked they were more concerned about releasing the next maintenance
> version).
>
> i'm not sure calling it a "functional" sort (not claiming that you
> did, i think it was someone else) is a good idea - probably best to
> avoid the f word :o)

If you want a sort that both sorts in-place and returns the result, write

    def sort(seq):
        seq.sort()
        return seq

and be done with it.  Likewise if you want a functional sort:

    def fsort(seq):
        return sort(list(seq))

Not every two-line Python function has to come pre-written <0.9 wink>.

> ...
> ps is the dsu speed advantage really significant?  i normally ignore
> log(n) factors (am i admitting to some terrible misdemeanour?!) as not
> being worth the bother...

Time it.  It's N log N either way, of course, the difference is in saving N
log N Python-level function calls.