Antoon Pardon wrote:
> Op 2005-10-25, Steven D'Aprano schreef <[EMAIL PROTECTED]>: >>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