[Numpy-svn] [numpy/numpy] bc41aa: MAINT: move the special case for string comparison...

[GitHub]

  Branch: refs/heads/binop-dispatch
  Home:   https://github.com/numpy/numpy
  Commit: bc41aa5acb7a8634720794958ca15b15f2b22d18
      https://github.com/numpy/numpy/commit/bc41aa5acb7a8634720794958ca15b15f2b22d18
  Author: Nathaniel J. Smith <njs at pobox.com>
  Date:   2015-05-11 (Mon, 11 May 2015)

  Changed paths:
    M numpy/core/src/multiarray/arrayobject.c

  Log Message:
  -----------
  MAINT: move the special case for string comparison before the regular case

The ndarray richcompare function has a special case for handling
string dtypes (which currently cannot be handled by
ufuncs). Traditionally this was handled by the ufuncs returning
NotImplemented, and then falling through to a special case. By moving
the special case to the top of the richcompare function, it becomes
unnecessary for the ufuncs to return NotImplemented in this case.


  Commit: 069f0ff6d46d982231d17e073d7c697c9514b4b2
      https://github.com/numpy/numpy/commit/069f0ff6d46d982231d17e073d7c697c9514b4b2
  Author: Nathaniel J. Smith <njs at pobox.com>
  Date:   2015-05-11 (Mon, 11 May 2015)

  Changed paths:
    M numpy/core/src/multiarray/arrayobject.c
    M numpy/core/tests/test_deprecations.py
    M numpy/core/tests/test_multiarray.py
    M numpy/testing/utils.py

  Log Message:
  -----------
  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.


  Commit: c3c819ae27c103b22ec0e7ce5924986a18b29c30
      https://github.com/numpy/numpy/commit/c3c819ae27c103b22ec0e7ce5924986a18b29c30
  Author: Nathaniel J. Smith <njs at pobox.com>
  Date:   2015-05-12 (Tue, 12 May 2015)

  Changed paths:
    M numpy/core/src/multiarray/number.c
    M numpy/ma/core.py
    M numpy/ma/tests/test_core.py

  Log Message:
  -----------
  MAINT: add __array_priority__ special case to masked array binary ops

ndarray special methods like __add__ have a special case where if the
right argument is not an ndarray or subclass, and it has higher
__array_priority__ than the left argument, then we return
NotImplemented and let the right argument handle the operation.

ufuncs have traditionally had a similar but different special case,
where if it's a 2 input - 1 output ufunc, and the right argument is
not an ndarray (exactly, subclasses don't count), and when converted
to an ndarray ends up as an object array (presumably b/c it doesn't
have a meaningful coercion route, though who knows), and it has a
higher __array_priority__ than the left argument AND it has a
__r<operation>__ attribute, then they return NotImplemented.

In practice this latter special case is not used by regular ndarrays,
b/c anytime it would need to be triggered, the former special case
triggers first and the ufunc is never called. However, numpy.ma did
not have the former special case, and was thus relying on the ufunc
special case. This commit adds the special case to the numpy.ma
special methods directly, so that they no longer depend on the quirky
ufunc behaviour.

It also cleans up the relevant test to things that actually should be
true in general, instead of just testing some implementation details.


  Commit: acd37c8b5486ab7ccaeb5397f7575f87eeb46961
      https://github.com/numpy/numpy/commit/acd37c8b5486ab7ccaeb5397f7575f87eeb46961
  Author: Nathaniel J. Smith <njs at pobox.com>
  Date:   2015-05-12 (Tue, 12 May 2015)

  Changed paths:
    M doc/release/1.10.0-notes.rst
    M numpy/core/src/multiarray/arrayobject.c
    M numpy/core/src/umath/ufunc_object.c
    M numpy/core/tests/test_deprecations.py
    M numpy/core/tests/test_indexing.py
    M numpy/core/tests/test_regression.py

  Log Message:
  -----------
  MAINT: Remove NotImplemented handling from ufuncs (almost)

This was redundant/broken anyway.

See gh-5844 for discussion. See the massive comment added to
ufunc_object.c:get_ufunc_arguments for a discussion of the deprecation
strategy here -- it turns out that array_richcompare is such a
disaster zone that we can't quite wholly eliminate NotImplemented
quite yet. But this removes most NotImplementeds, and lays the
groundwork for eliminating the rest in a release or two.


  Commit: ec8e60096276f80cb3acb02a7dbb5001e5f73bfb
      https://github.com/numpy/numpy/commit/ec8e60096276f80cb3acb02a7dbb5001e5f73bfb
  Author: Nathaniel J. Smith <njs at pobox.com>
  Date:   2015-05-14 (Thu, 14 May 2015)

  Changed paths:
    M numpy/core/tests/test_deprecations.py

  Log Message:
  -----------
  MAINT: give more details on assert_deprecation failures

Hopefully this will let me debug the failing Travis test, since I
can't reproduce it locally..


Compare: https://github.com/numpy/numpy/compare/bc41aa5acb7a^...ec8e60096276