Would there be support for a more general cmp/__cmp__

Antoon Pardon apardon at forel.vub.ac.be
Wed Oct 26 10:37:42 CEST 2005


Op 2005-10-25, Steven D'Aprano schreef <steve at REMOVETHIScyber.com.au>:
> On Tue, 25 Oct 2005 10:09:29 -0400, Christopher Subich wrote:
>
>>>>By analogy, one can ask, "is the cat inside the box?" and get the answer
>>>>"No", but this does not imply that therefore the box must be inside the
>>>>cat.
>>> 
>>> 
>>> Bad analogy, this doesn't define a mathematical ordering, the subset
>>> relationship does.
>> 
>> Yes, it does.  Consider "in" as a mathematical operator:
>>
>> For the set (box, cat-in-box)
>> 
>> box in box: False
>> box in cat-in-box: False
>> cat-in-box in box: True
>> cat-in-box in cat-in-box: False
>> 
>> For the set (box, smart-cat) # cat's too smart to get in the box
>> 
>> box in box: False
>> box in smart-cat: False
>> smart-cat in box: False
>> smart-cat in smart-cat: False
>> 
>> In both these cases, the "in" operator is irreflexive, asymmetric, and 
>> transitive (extend to mouse-in-cat if you really care about transitive), 
>> so "in" is a partial order sans equality.  A useless one, but a partial 
>> order nonetheless.
>
> What do you mean "in" is a useless ordering? It makes a huge difference
> whether "nuclear bomb in New York" is true or not.
>
> In fact, I'm quite surprised that Antoon should object to "in" as "this
> doesn't define a mathematical ordering, the subset relationship does" when
> "subset" is just "in" for sets: set S is a subset of set T if for all
> elements x in S, x is also in T. Informally, subset S is in set T.

I was misunderstaning where Christopher was heading to.

> Can somebody remind me, what is the problem Antoon is trying to solve here?

Well there are two issues. One about correct behaviour and one about
practicallity.

The first problem is cmp. This is what the documentation states:

cmp(x, y)
    Compare the two objects x and y and return an integer according to
    the outcome. The return value is negative if x < y, zero if x == y
    and strictly positive if x > y. 

The problem is, that if someone implements a partial ordered class,
with the rich comparisons, cmp doesn't behave correct. It can't
behave correct because it will always give an number as a result
and such a number implies one of three relations between two
elements, but with partial ordered classes, it is possible none
of these relations exist between those two elements. So IMO cmp
should be changed to reflect this. This can be done either by cmp
returning None or UnequalValues.  or by cmp raising UnequalValues
in such a case.

The second part is one of practicallity. Once you have accepted cmp,
should reflect this possibility, it makes sense that the __cmp__
method should get the same possibilities, so that where it is more
pratical to do so, the programmer can implement his partial order
through one __cmp__ method instead of having to write six.


In my opinion such a change would break no existing code. This
is because there are two possibilities.

1) The user is using cmp on objects that form a total order.
In such circumstances the behaviour of cmp doesn't change.

2) The user is using cmp on objects that don't form a total
order. In such circumstances cmp doesn't give consistent
results, so the code is already broken.

-- 
Antoon Pardon



More information about the Python-list mailing list