unittest wart/bug for assertNotEqual
Ethan Furman
ethan at stoneleaf.us
Tue Oct 20 18:57:19 EDT 2009
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~
More information about the Python-list
mailing list