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.
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.
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.
"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
>
--
https://mail.python.org/mailman/listinfo/python-list
