Antoon Pardon wrote:
> Op 2005-10-25, Christopher Subich schreef <[EMAIL PROTECTED]>:
>>
>>My biggest complaint here is about returning None or IncomparableValue;
>>if that happens, then all code that relies on cmp returning a numeric
>>result will have to be rewritten.
>
>
> I don't know. There are two possibilities.
>
> 1) The user is working with a total order. In that case the None
> or IncomparableValues won't be returned anyway so nothing about
> his code has to change.
>
> 2) The user is working with a partial order. In that case cmp
> doesn't provide consistent results so the use of cmp in this
> case was a bug anyway.
Case 3) The user is working with an unknown class, using duck typing,
and expects a total order. If cmp suddenly returned Incomparable or
None, the code would break in Unexpected Ways, with Undefined Behavior.
This is a classic "exception versus error code" argument; in this case,
returning None would be the error flag. It's almost always better to
just throw the exception, because then this allows error-checking at a
more natural level.
>>As for saying that cmp should return some times and raise an exception
>>other times, I just find it squicky.
>
>
> But cmp already behaves this way. The only difference would be that
> the decision would be made based on the values of the objects instead
> of only their class.
>
>
>>Admittedly, this is entirely up to
>>the class designer, and your proposed guideline wouldn't change cmp's
>>behavior for clases that /are/ totally ordered.
>>
>>Then again, sets excepted, your guideline doesn't seem very applicable
>>in standard library code.
>
>
> Well AFAIAC this isn't specific about library code.
A change that cmp return a 4th possible "value" (None or Incomparable)
is a fundamental language change. Because this would break large
amounts of existing code, it's a bad idea.
A change that cmp throw an exception iff the two objects, rather than
the two classes, were incomparable (allowing comparisons of( 1+0j and
2+0j) and ({a} and {a,b}) but not (1+1j and 2+0j) and ({a} and {b})) is
a stylistic guideline, since it's already possible to write your own
classes this way. The only place this change would matter is in the
standard library code, and in just a few places at that.
--
http://mail.python.org/mailman/listinfo/python-list
