unittest wart/bug for assertNotEqual

[Ethan Furman]

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~