[Python-3000] ABC for Inequalities

[Neil Toronto]

Guido van Rossum wrote:
> On Feb 11, 2008 7:31 PM, Raymond Hettinger <python at rcn.com> wrote:
>> [GvR]
>>> The problem is that if you have two instance x,
>>> y such that isinstance(x, TotalOrdering) and isinstance(y,
>>> TotalOrdering) you still don't know if x < y is defined. (For example,
>>> if x is a string and y is a number.)
>> So, ordering only makes sense when "other" is known to be
>> of the same type as "self".
> 
> No, that's too far in the other direction. E.g. two instances of Real
> but of different implementations should still be comparable. (Though I
> expect there's some higher math involved to prove this for all reals.
> :-)

The problem is that, like all the binary operators, "orderable" is only 
defined for pairs of types. A single declaration of orderable-ness 
necessarily lacks information needed for type safety.

>>> There's a useful definition in there somewhere but
>>> it's elusive. We'll eventually figure it out.
>> I hope so. I'm less interested in the mixin and more interested in
>> a way for a class to have a way to tell you whether it is sortable.
>> Right now, the presence or absence of __le__ doesn't tell
>> you much.
> 
> Yeah, this is one area where a leap of faith (a.k.a. duck typing :-)
> may still be the best approach.
> 
> I think you can probably get something that is reasonable given the
> kind of assumptions that prevail in an ABC world by having a
> "Sortable" metaclass (itself a subclass of ABCMeta) with the implied
> semantics that objects x and y can be sorted if the nearest common
> ancestor of x.__class__ and y.__class__ is an instance of Sortable.

Besides probably not being "worth it" (as you say), forcing the classes 
into an inheritance hierarchy doesn't seem Pythonic. (I may not have the 
Python-fu to make such declarations, but I'll call 'em as I see 'em.) 
Also, x objects and y objects may be orderable homogeneously, but not 
heterogeneously. I could impose a total order on sets of circles and 
another on sets of squares without imposing an order on sets of both 
circles and squares, and not be able to spell this under the inheritance 
approach.

To do it properly beyond duck typing, there should be a way to ask 
whether (and declare that) a *pair* of types implements an interface 
such as Orderable. This is analogous to how the binary operators 
currently work, though those are decentralized: the op/rop methods 
jointly decide what's legal.

A little voice in my head is shouting "icky!" at the prospects.

IIRC, one major motivation for ABCs was to avoid calling potentially 
destructive methods by allowing interface queries first. Does anyone 
expect comparisons to be destructive?

Where would an "Orderable" query happen? Not before sorting a list - 
you'd have to scan the list to see what types are in it. (And declaring 
orderability for just pairs of types may not be enough then. Is 
orderability transitive?) Before each comparison? If that's the case, 
the only reason I can see for checking for Orderable is to keep people 
from doing dumb things.

Neil