[Python-Dev] Tuples and underorderable types

Fri Apr 24 23:36:54 CEST 2009

Raymond Hettinger wrote:
> Does anyone have any ideas about what to do with issue 5830 and handling 
> the problem in a general way (not just for sched)?
>> The basic problem is that decorate/compare/undecorate patterns no longer 
> work when the primary sort keys are equal and the secondary keys are 
> unorderable (which is now the case for many callables).
>> >>> tasks = [(10, lambda: 0), (20, lambda: 1), (10, lambda: 2)]
> >>> tasks.sort()
> Traceback (most recent call last):
> ...
> TypeError: unorderable types: function() < function()
>> Would it make sense to provide a default ordering whenever the types are 
> the same?
>> def object.__lt__(self, other):
> if type(self) == type(other):
> return id(self) < id(other)
> raise TypeError

The immediate problem with this is that 'same type', or not, is 
sometimes a somewhat arbitrary implementation detail. In 2.x, 
4000000000 could be int or long, depending on the build. In 3.0, that 
difference disappeared. User-defined and builtin functions are 
different classes for implementation, not conceptual reasons. (This 
could potentially bite what I understand to be your r71844/5 fix.) 
Unbound methods used to be the same class as bound methods (as I 
remember). In 3.0, the wrapping disappeared and they are the same thing 
as the underlying function. In 2.x, ascii text and binary data might 
both be str. Now they might be str and bytes.
Universal ordering and default ordering by id was broken (and doomed) 
when Guido decided that complex numbers should not be comparable either 
lexicographically or by id. Your proposed object.__lt__ would reverse 
that decision, unless, of course, complex was special-cased (again) to 
over-ride it, but then we would be back to the 2.x situation of mixed 
rules and exceptions.
Terry Jan Reedy