Repository navigation
BUG: Vague error message from ufunc np.any #20898
Description
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 typeNumPy/Python version information:
1.22.1 3.10.2 | packaged by conda-forge | (main, Jan 14 2022, 08:02:37) [Clang 11.1.0 ]
Activity
seberg commentedon Jan 26, 2022
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 commentedon Jan 26, 2022
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 commentedon Feb 9, 2022
We discussed this a bit (in the triage meeting), and settled on just rejecting strings explicitly for now, because this is a bit weird.
API: Disallow strings in logical ufuncs
API: Disallow strings in logical ufuncs (#21024)
API: Disallow strings in logical ufuncs (numpy#21024)
API: Disallow strings in logical ufuncs (numpy#21024)
API: Disallow strings in logical ufuncs (numpy#21024)