sorting list of complex numbers

[Terry Reedy]

Paul Rubin wrote:

> That only goes so far though.  Suppose instead of complex numbers
> you want to sort expressions, like:
> 
>     a(b,c(d,e),f(g,h))
> 
> treat those as parse trees in the obvious way.

Presuming that a, c, and f are function calls that return Tree 
instances, you give Tree a __lt__ member that does what you say below.

> You want to compare on
> the root, and if the roots are equal, compare the left subtree, then
> the right subtree, etc.

 >  Do you REALLY want to sort over and over
> all the way to the max depth of all the trees?

Don't understand this.

> I don't understand what the purpose of was of getting rid of the cmp
> arg.

Cmp requires a 3-way classification.  Sorting only requires 2-way.
cmp was called nlogn times, key n times.
cmp in practical use amounted to calling some key function on both 
items, so cmp amounted to 2*n*log(n) key calls pluse extra overhead.

> Another thing that apparently broke was tuple destructuring in
> function args.  You can no longer say
> 
>    def first((a,b)): return a
>    def second((a,b)): return b
> 
> make getters for the first and second elements of a tuple.  Sure, you
> could use operator.itemgetter for that example, but often you want to
> parse out more complicated nested tuples.  I do that all the time with
> Python 2.5 (typically in conjunction with itertools.groupby) but
> if/when I downgrade to 3.0, a bunch of my code is going to break.

Do your tuple destructuring in the first statement in your body and 
nothing will break.  Don't upgrade until it is an upgrade for *you*.