Python 3.0 - is this true?

[Terry Reedy]

Duncan Grisby wrote:

> Yes, very hard.

There is a difference between 'very hard' (to get 'right') and 'to slow' 
(for a particular application).  I accept the latter.

> There are only ever simple types in the lists --
> strings, integers, Nones, very occasionally floats, and lists of those
> things. The sort is always predictable with those types. Just because
> you can contrive situations to demonstrate unpredictable sorts doesn't
> mean that all sorts with mixed types are unpredictable.

The 2.5 manual (and I sure before that) *intentially* defines the 
default cross-type comparisons as unreliable.

"(This unusual definition of comparison was used to simplify the 
definition of operations like sorting and the in and not in operators. 
In the future, the comparison rules for objects of different types are 
likely to change.)"

They have changed in the past and now they change again (yes, a little 
more drastically this time, but as expected for some years).

> The sorting is in a performance-critical part of the system, so the
> overhead of evaluating a key function is not insignificant. A key
> function that returns objects that contrive to emulate the
> functionality of a comparison function is definitely not appropriate.
> That area of the system already builds the lists using C++ for speed,
> so if we ever migrate to Python 3 it will probably be easier to do the
> whole thing in C++ rather than jump through hoops to make the Python
> sort work efficiently enough.

Assuming the premises, agreed.  No hurry, but you can even pull 
timsort() out of the source, if you otherwise like its large-list 
behavior, and hardcode the comparison function.

Terry Jan Reedy