metaclasses for type comparison

[Simon Burton]

In today's experiment, I was wondering if I could make the comparison
operators (<,<=,>=,>) work on classes (types) according to inheritance.

The idea is, for example, classes lower in the class hierarchy would be
less than (more specialized) than classes they inherit from.

class A(object):
pass

class B(A):
pass

B < A # should be True

In my first attempt I tried putting __lt__ into the class definition for A
and then assigning it as a staticmethod. This doesn't work, but something
was happening; <,<=,>=,> are still valid as applied to classes.

Because class is to instance as metaclass is to class, I found that the
place to put these methods is in the class' metaclass.

class MetaCMP(type):
def __lt__(cls,other):
for base in cls.__bases__:
if type(base) != cls.__class__:
continue
if base <= other:
return 1
return 0

def __le__(cls,other):
if cls == other:
return 1
for base in cls.__bases__:
if type(base) != cls.__class__:
continue
if base <= other:
return 1
return 0

def __gt__(cls,other):
for base in other.__bases__:
if type(base) != cls.__class__:
continue
if cls >= base:
return 1
return 0

def __ge__(cls,other):
if cls == other:
return 1
for base in other.__bases__:
if type(base) != cls.__class__:
continue
if cls >= base:
return 1
return 0

__metaclass__ = MetaCMP

Now, with the above code, we can replace a call to isinstance.

type( B() ) <= A # True

It seems natural enough to my math trained eye.

But now we have non-comparible objects, which confuses the sorting issue.

class C:
pass

C < A # False
A < C # False

For example, if we wanted a "total" order ( always either X<=Y or Y<=X )
we could remove __ge__ and __gt__ from MetaCMP. It's not clear to me
exactly which comparison methods "list.sort" uses. (The ideal sort here is
the topological sort.)

I also thought about extending this order so that "B() <= A" would behave
the same way. It would be rather more strange. Is it so natural that an
instance is "smaller" than it's type? Perhaps; the instance can have
attributes that override it's type, which is reminiscent of some kinds of
inheritance.

Finally, the feature request. If "type" implemented these semantics for
comparison would it break existing code? Does anyone rely on "1<dict"
being True, or that we have a total order (one of "<","==" or ">" always
True) ? Another quandry is that one could just as naturally argue for the
reverse ordering.

Comments sought (can you guess what + might do to classes?).

Simon Burton.

[David C. Fox]

Simon Burton wrote:

In today's experiment, I was wondering if I could make the comparison
operators (<,<=,>=,>) work on classes (types) according to inheritance.

The idea is, for example, classes lower in the class hierarchy would be
less than (more specialized) than classes they inherit from.

class A(object):
pass

class B(A):
pass

B < A # should be True

Is this an exercise to help you learn about metaclasses, or do you
actually want to be able to check whether B is a subclass of A. If the
latter, then try issubclass(B, A). Otherwise, ignore this comment

David

[Simon Burton]

On Thu, 11 Sep 2003 03:03:02 +0000, David C. Fox wrote:

....

B < A # should be True

Is this an exercise to help you learn about metaclasses, or do you
actually want to be able to check whether B is a subclass of A. If the
latter, then try issubclass(B, A). Otherwise, ignore this comment

David

Both. Well, aha, "issubclass" makes my implementation
of ge/le and friends a bit silly. Actually i was annoyed
with "isinstance", it seems like it should be part of the syntax
(eg."<="). Look at this: "issubclass". It has 10 chars!!

Lazy when i can be,

Simon Burton.

[David Eppstein]

In article <pa****************************@webone.com.au>,
Simon Burton <si****@webone.com.au> wrote:

Both. Well, aha, "issubclass" makes my implementation
of ge/le and friends a bit silly. Actually i was annoyed
with "isinstance", it seems like it should be part of the syntax
(eg."<="). Look at this: "issubclass". It has 10 chars!!

<= is supposed to be a total ordering, so it is not a good idea to use
it for partial orders such as subclass hierarchies.

--
David Eppstein http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science

[Gonçalo Rodrigues]

On Thu, 11 Sep 2003 11:45:01 -0700, David Eppstein
<ep******@ics.uci.edu> wrote:

In article <pa****************************@webone.com.au>,
Simon Burton <si****@webone.com.au> wrote:

Both. Well, aha, "issubclass" makes my implementation
of ge/le and friends a bit silly. Actually i was annoyed
with "isinstance", it seems like it should be part of the syntax
(eg."<="). Look at this: "issubclass". It has 10 chars!!

<= is supposed to be a total ordering, so it is not a good idea to use
it for partial orders such as subclass hierarchies.

Is it? I never came across such a supposition, which in itself says
nothing because I have very little experience anyway, but what about
set inclusion in the sets module which can be written as <=?

With my best regards,
G. Rodrigues

[David Eppstein]

In article <q6********************************@4ax.com>,
Gon?alo Rodrigues <op*****@mail.telepac.pt> wrote:

<= is supposed to be a total ordering, so it is not a good idea to use
it for partial orders such as subclass hierarchies.

Is it? I never came across such a supposition, which in itself says
nothing because I have very little experience anyway, but what about
set inclusion in the sets module which can be written as <=?

I don't have 2.3 yet, so haven't used sets yet, but what happens if you
try to sort a list of sets?

I found a message
<http://mail.python.org/pipermail/pyt...nuary/015454.h
tml> from Guido wondering about this but didn't see what the response
was...

--
David Eppstein http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science