On 2018-01-08 01:31, breamore...@gmail.com wrote: > On Monday, January 8, 2018 at 12:02:09 AM UTC, Ethan Furman wrote: >> On 01/07/2018 12:33 PM, Chris Angelico wrote: >>> On Mon, Jan 8, 2018 at 7:13 AM, Thomas Jollans wrote: >>>> On 07/01/18 20:55, Chris Angelico wrote: >>>>> Under what circumstances would you want "x != y" to be different from >>>>> "not (x == y)" ? >>>> >>>> In numpy, __eq__ and __ne__ do not, in general, return bools. >>>> >>>>>>> a = np.array([1,2,3,4]) >>>>>>> b = np.array([0,2,0,4]) >>>>>>> a == b >>>> array([False, True, False, True], dtype=bool) >>>>>>> a != b >>>> array([ True, False, True, False], dtype=bool) >>> >>> Thanks, that's the kind of example I was looking for. Though numpy >>> doesn't drive the core language development much, so the obvious next >>> question is: was this why __ne__ was implemented, or was there some >>> other reason? This example shows how it can be useful, but not why it >>> exists. >> >> Actually, I think it is why it exists. If I recall correctly, the addition >> of the six comparative operators* was added >> at the behest of the scientific/numerical community. >> >> -- >> ~Ethan~ >> >> * Yeah, I can't remember the cool name for those six operators at the >> moment. :( > > The six rich comparison methods were added to 2.1 as a result of PEP 207, > which confirms that you're correct, they were added at the request of the > numpyites.
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__? > > -- > Kindest regards. > > Mark Lawrence. > -- https://mail.python.org/mailman/listinfo/python-list
