Deprecation warnings in assert_array_equal

[larsoner]

Related to the multiple issues about np.array(x) emitting a deprecation warning, it appears that np.testing.assert_array_equal emits a warning when the arguments get cast to an object array. This should probably not emit such a warning:

>>> import numpy as np
>>> import warnings
>>> warnings.simplefilter('always')
>>> np.testing.assert_array_equal([['a', 'b'], ['c']], [['a', 'b'], ['c']])
/home/larsoner/python/numpy/numpy/testing/_private/utils.py:709: DeprecationWarning: Creating an ndarray with automatic object dtype is deprecated, use dtype=object if you intended it, otherwise specify an exact dtype
  x = array(x, copy=False, subok=True)
/home/larsoner/python/numpy/numpy/testing/_private/utils.py:710: DeprecationWarning: Creating an ndarray with automatic object dtype is deprecated, use dtype=object if you intended it, otherwise specify an exact dtype
  y = array(y, copy=False, subok=True)

For projects that use warnings-as-errors in CIs, assert_array_equal on things that get cast to object arrays is now problematic. There might be other members of np.testing with a similar issue.

Perhaps assert_array_equal should make use of the warning-catching suggested in #15047, but the non-thread-safeness of catch_warnings makes me a bit wary of this solution.

[mattip]

I think the intention here is to only use assert_array_equal on ndarrays. So could you modify your code to do

np.testing.assert_array_equal(np.array([['a', 'b'], ['c']], dtype=object),
                                   np.array([['a', 'b'], ['c']], dtype=object)

?

[seberg]

Indeed, I am not sure this (or possibly even the general issue with ==) is an unintended side effect, as opposed to just a bit confusing/unexpected on first sight.
The main issue I see is the matplotlib one in gh-15047

[larsoner]

I think the intention here is to only use assert_array_equal on ndarrays.

The issue I see is that previously working / valid assert_array_equal code now emits a warning, which can break things downstream. If assert_array_equal is in fact meant to work for object-array-like things and we were just getting lucky before, then I don't see why it should emit a warning when you use it with one. If it's not meant to be used with object arrays, it would be better to catch the dep warning and emit a new one saying "assert_array_equal is not meant to be used with object arrays", which will then later automatically become an error when "object-array-like without explicit dtype='O' is an error" lands in np.asarray/np.array.

FWIW it seems like assert_array_equal not working with object arrays is a bit odd, since from my user/dev perspective object arrays are more or less just an ndarray with a particular dtype that will triage the underlying == operation.

So could you modify your code to do

Yes this is a possible workaround. The issue is that there could be tens or hundreds of such cases in a given code base. Then of course you could write your own a assert_array_equal wrapper to safely do this casting, etc. But then the issue is that there are many codebases, and any repo that has this assert_array_equal on object-array-likes will have to do this. For us it was easy enough just to change our handful of instances to assert a == b (since we just had lists of lists of strings, so == worked fine). But this might cause more systematic problems in the ecosystem.

Adapting assert_array_equal to squash the deprecation warning and cast in a future-compatible way, or explicitly disallow object arrays (via deprecation cycle with warning), might be a nice thing to do for folks. But this could also be enough of a corner case problem that it's not worth dealing with. I'll close since this might be the case. At least others might find this issue now if they search, and if it they hit the problem they can chime in, too.