Comparison of functions

[Rocco Moretti]

Adriano Varoli Piazza wrote:

> As far as I recall from Math Analysis, which I studied two months ago, 
> you can't sort complex numbers. It makes no sense. The reason being 
> (reading from my book), it's not possible to define an order that 
> preserves the properties of arithmetical operations on complex numbers. 
> So you can't order them, and you can't compare them.

Debate the merits of Python's method of sorting all you want, but for 
the love of all that is good and holy, please do not claim that the 
current way of doing things is somehow mathematically pure. The best 
explanation of the current method is that it is a compromise borne out 
of the best use cases encountered as the language grew in it's infancy, 
and we're stuck with it currently because it would break too much to 
change things right now.

E.g.:
1 < '2' => True
'1' < 2 => False
20 < 'Five' => True
None < 0 => True
[1,2] < (1,2) => True
(1,2) < [100,200] => False
(None,) < None => False
{1:None,2:None} < [1,2] => True

[None, 1, 'five', open('README'), (1,2,3)].sort() => works just fine
[None, 1, 'five', open('README'), (1,2,3), 1j].sort() => crashes and burns

None of these make sense mathematically, nor were they motivated 
primarily by mathematical arguments. Why is [1,2] < (1,2)? Because 
'list' < 'tuple' - No more, no less.

One could argue that you could think of complex numbers as tuples of 
values - but then why does
[(1,2),(4,1),(4,-3),(7.2,-1.2)].sort() work and
[(1+2j),(4+1j),(4-3j),(7.2-1.2j)].sort() fail?

"Practicality beats purity." Python has it's current ordering/sorting 
scheme not because it is theoretically pure, but because it seemed like 
the best option at the time. Please don't pretend it's perfect - it's 
even been admitted that things are going to change in the future, 
although I haven't yet seen a conversation where it has been made clear 
exactly what will change.