On 2018-01-08 15:25, Oren Ben-Kiki wrote:
> I don't see a case in IEEE where (x == y) != !(x != y).
> There _is_ a case where (x != x) is true (when x is NaN), but for such an
> x, (x == x) will be false.
>
> I am hard pressed to think of a case where __ne__ is actually useful.
See my earlier email and/or PEP 207. (tl;dr: non-bool return values)
>
> That said, while it is true you only need one of (__eq__, __ne__), you
> could make the same claim about (__lt__, __ge__) and (__le__, __gt__).
> That is, in principle you could get by with only (__eq__, __le__, and
> __ge__) or, if you prefer, (__ne__, __lt__, __gt__), or any other
> combination you prefer.
PEP 207: "The above mechanism is such that classes can get away with not
implementing either __lt__ and __le__ or __gt__ and __ge__."
>
> Or you could go where C++ is doing and say that _if_ one specifies a single
> __cmp__ method, it should return one of LT, EQ, GT, and this will
> automatically give rise to all the comparison operators.
This used to be the case. (from version 2.1 to version 2.7, AFAICT)
>
> "Trade-offs... trafe-offs as far as the eye can see" ;-)
>
>
> On Mon, Jan 8, 2018 at 4:01 PM, Thomas Nyberg <tomuxi...@gmx.com> wrote:
>
>> On 01/08/2018 12:36 PM, Thomas Jollans wrote:
>>>
>>> Interesting sentence from that PEP:
>>>
>>> "3. The == and != operators are not assumed to be each other's
>>> complement (e.g. IEEE 754 floating point numbers do not satisfy this)."
>>>
>>> Does anybody here know how IEE 754 floating point numbers need __ne__?
>>
>> That's very interesting. I'd also like an answer to this. I can't wrap
>> my head around why it would be true. I've just spent 15 minutes playing
>> with the interpreter (i.e. checking operations on 0, -0, 7,
>> float('nan'), float('inf'), etc.) and then also reading a bit about IEEE
>> 754 online and I can't find any combination of examples where == and !=
>> are not each others' complement.
>>
>> Cheers,
>> Thomas
--
https://mail.python.org/mailman/listinfo/python-list
