Steven D'Aprano wrote:
On Tue, 20 Oct 2009 14:45:49 -0700, Zac Burns wrote:
My preference would be that failIfEqual checks both != and ==. This is
practical, and would benefit almost all use cases. If "!=" isn't "not
==" (IEEE NaNs I hear is the only known use case)
numpy uses == and != as element-wise operators:
import numpy
a = numpy.array([10, 20, 30, 40])
b = numpy.array([10, 20, 31, 40])
a==b
array([ True, True, False, True], dtype=bool)
a!=b
array([False, False, True, False], dtype=bool)
not a!=b
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: The truth value of an array with more than one element is
ambiguous. Use a.any() or a.all()
then those could simply not use this method.
I'm not so sure this is a good idea. Python specifically treats == and !=
as independent. There's no reason to think that a class must have both,
or that it's an error if it defines == without !=, or even that they are
reflections of each other. numpy doesn't, and that's a pretty huge
counter-example.
It would not surprise me if changing this would bring to light many
existing bugs.
It would surprise me.
Two issues: 1) Sounds like we should have two more Asserts --
failIfNotEqual, and assertNotNotEqual to handle the dichotomy in Python;
and 2) Does this mean (looking at Mark Dickinson's post) that 2.7 and
3.1 are now broken?
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
