diff options
author | Nathaniel J. Smith <njs@pobox.com> | 2015-05-07 20:24:06 -0700 |
---|---|---|
committer | Charles Harris <charlesr.harris@gmail.com> | 2015-06-13 12:32:54 -0600 |
commit | 1e3ab40493fadb5daa67c8a55c5360fd934cca7b (patch) | |
tree | b33e523decb2dbbd27e3a89d01ae3532527d91b9 /numpy/core/fromnumeric.py | |
parent | 4b1f508a57549d8031a23160b40c7f87f47892ed (diff) | |
download | numpy-1e3ab40493fadb5daa67c8a55c5360fd934cca7b.tar.gz |
MAINT: move the special case for void comparison before the regular case
The ndarray richcompare function has special case code for handling
void dtypes (esp. structured dtypes), since there are no ufuncs for
this. Previously, we would attempt to call the relevant
ufunc (e.g. np.equal), and then when this failed (as signaled by the
ufunc returning NotImplemented), we would fall back on the special
case code. This commit moves the special case code to before the
regular code, so that it no longer requires ufuncs to return
NotImplemented.
Technically, it is possible to define ufunc loops for void dtypes
using PyUFunc_RegisterLoopForDescr, so technically I think this commit
changes behaviour: if someone had registered a ufunc loop for one of
these operations, then previously it might have been found and
pre-empted the special case fallback code; now, we use the
special-case code without even checking for any ufunc. But the only
possible use of this functionality would have been if someone wanted
to redefine what == or != meant for a particular structured dtype --
like, they decided that equality for 2-tuples of float32's should be
different from the obvious thing. This does not seem like an important
capability to preserve.
There were also several cases here where on error, an array comparison
would return a scalar instead of raising. This is supposedly
deprecated, but there were call paths that did this that had no
deprecation warning. I added those warnings.
Diffstat (limited to 'numpy/core/fromnumeric.py')
0 files changed, 0 insertions, 0 deletions