[Numpy-discussion] Allow == and != to raise errors

[Nathaniel Smith]

On Fri, Jul 12, 2013 at 2:13 PM, Benjamin Root <ben.root at ou.edu> wrote:
> I can see where you are getting at, but I would have to disagree.  First of
> all, when a comparison between two mis-shaped arrays occur, you get back a
> bone fide python boolean, not a numpy array of bools. So if any action was
> taken on the result of such a comparison assumed that the result was some
> sort of an array, it would fail (yes, this does make it a bit difficult to
> trace back the source of the problem, but not impossible).
>
> Second, no semantics are broken with this. Are the arrays equal or not? If
> they weren't broadcastible, then returning False for == and True for !=
> makes perfect sense to me. At least, that is my take on it.

But it does break semantics. Sure, it tells you that the arrays aren't
equal -- but that's not the question you asked. "==" is not "are these
arrays equal"; it's "is each pair of broadcasted aligned elements in
these arrays equal", and these are totally different operations. It's
unfortunate that "==" is a somewhat confusing name, but that's no
reason to mix things up like this. "+" in python sometimes means "add
all elements" and sometimes means "concatenate", but no-one would
argue that ndarray.__add__ should the former when the arrays were
broadcastable and the latter when they weren't. This is the same
thing.

"Errors should never pass silently", "In the face of ambiguity, refuse
the temptation to guess."

There's really no sensible interface here -- notice that '==' can
return False but can never return True, and Josef gave an example of
where it can silently produce misleading results. So to me it seems
like a clear bug, but one of the sort that has a higher probability
than usual that someone somewhere is depending on it... which makes it
less clear what exactly to do with it.

I guess one option is to just start raising errors in the first RC and
see whether anyone complains! But people people don't seem to test the
RCs enough to make this entirely reliable :-(.

-n