[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: Antoon Pardon <apardon () forel ! vub ! ac ! be>
Date: 2005-10-27 8:27:53
Message-ID: slrndm13s8.hdl.apardon () rcpc42 ! vub ! ac ! be
[Download RAW message or body]
Op 2005-10-26, Christopher Subich schreef <csubich.spam.block@spam.subich.block.com>:
> Antoon Pardon wrote:
>> Op 2005-10-25, Christopher Subich schreef <csubich.spam.block@spam.subich.block.com>:
>>>
>>>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 case 2. Under the current circumstances working with cmp with
a partial order will give inconsistent behaviour. So your code is
already broken for relying on cmp to give consistent results in
circumstances it can't.
> 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.
If you prefer a raised exception, I could live with that.
>>>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.
I have always included the option that cmp would raise an exception
instead of returning a fourth value.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic