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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
