BUG: Vague error message from ufunc np.any

[jakirkham]

Describe the issue:

Noticed with NumPy 1.22 that the error message from np.any is a bit vague. However NumPy 1.21 has a clearer error message. Interestingly the error type raised changed from TypeError to ValueError.

Reproduce the code example:

In [1]: import numpy as np

In [2]: a = np.array(["baz", "baz", "baz", "bar", "foo"], dtype="<U3")

In [3]: a.any()

Error message:

The NumPy 1.22 error message is:

---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Input In [3], in <module>
----> 1 a.any()

File ~/miniconda/envs/np122/lib/python3.10/site-packages/numpy/core/_methods.py:57, in _any(a, axis, dtype, out, keepdims, where)
     54 def _any(a, axis=None, dtype=None, out=None, keepdims=False, *, where=True):
     55     # Parsing keyword arguments is currently fairly slow, so avoid it for now
     56     if where is True:
---> 57         return umr_any(a, axis, dtype, out, keepdims)
     58     return umr_any(a, axis, dtype, out, keepdims, where=where)

ValueError: invalid literal for int() with base 10: 'baz'

Compare this to the previous error message from NumPy 1.21, which was:

---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Input In [3], in <module>
----> 1 a.any()

File ~/miniconda/envs/np121/lib/python3.10/site-packages/numpy/core/_methods.py:57, in _any(a, axis, dtype, out, keepdims, where)
     54 def _any(a, axis=None, dtype=None, out=None, keepdims=False, *, where=True):
     55     # Parsing keyword arguments is currently fairly slow, so avoid it for now
     56     if where is True:
---> 57         return umr_any(a, axis, dtype, out, keepdims)
     58     return umr_any(a, axis, dtype, out, keepdims, where=where)

TypeError: cannot perform reduce with flexible type

NumPy/Python version information:

1.22.1 3.10.2 | packaged by conda-forge | (main, Jan 14 2022, 08:02:37) [Clang 11.1.0 ]

[seberg]

Hmmm, it now behaves like arr.astype(bool) instead of failing immediately. Which I think is better in principle, but the truthiness of NumPy strings is a giant mess still :(.

[jakirkham]

At least from a user perspective, it wasn't clear to me what was going wrong whereas the original error message this was clear

[seberg]

We discussed this a bit (in the triage meeting), and settled on just rejecting strings explicitly for now, because this is a bit weird.