[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-list
Subject:    Re: Would there be support for a more general cmp/__cmp__
From:       Ron Adam <rrr () ronadam ! com>
Date:       2005-10-26 13:16:13
Message-ID: xkL7f.213784$p_1.11962 () tornado ! tampabay ! rr ! com
[Download RAW message or body]



Antoon Pardon wrote:

> Op 2005-10-25, Steven D'Aprano schreef <steve@REMOVETHIScyber.com.au>:

>>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.

Instead of changing cmp, why not just have several common versions to 
choose from instead of trying to make one tool do it all?

> 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.


Adding complexity to cmp may not break code, but it could probably slow 
down sorting in general.  So I would think what ever improvements or 
alternatives needs to be careful not to slow down existing sorting cases.

Cheers,
    Ron

-- 
http://mail.python.org/mailman/listinfo/python-list
[prev in list] [next in list] [prev in thread] [next in thread]