diff options
author | Sebastian Berg <sebastian@sipsolutions.net> | 2020-07-24 11:40:24 -0500 |
---|---|---|
committer | Sebastian Berg <sebastian@sipsolutions.net> | 2020-07-24 11:40:24 -0500 |
commit | d45b16dae51f9e8fa9b8296677e7a186b5efbc4a (patch) | |
tree | daa6adc8ab52468a9a2dfee2f4f37c710b4b6ff9 /numpy/array_api/tests/test_indexing_functions.py | |
parent | 2d12d0c2f7ac7b5e79d95b958b4c75871029b9a6 (diff) | |
download | numpy-d45b16dae51f9e8fa9b8296677e7a186b5efbc4a.tar.gz |
BUG: Allow array-like types to be coerced as object array elements
This was previously allowed for nested cases, i.e.:
np.array([np.int64])
but not for the scalar case:
np.array(np.int64)
The solution is to align these two cases by always interpreting
these as not being array-likes (instead of invalid array-likes)
if the passed in object is a `type` object and the special
attribute has a `__get__` attribute (and is thus probable a
property or method).
The (arguably better) alterative to this is to move the special
attribute lookup to be on the type instead of the instance
(which is what python does). This will definitely require some
adjustments in our tests to use properties, but is probably
fine with respect to most actual code.
(The tests more commonly use this to quickly set up an
array-like, while it is a fairly strange pattern for typical code.)
Address parts of gh-16939
Closes gh-8877
Diffstat (limited to 'numpy/array_api/tests/test_indexing_functions.py')
0 files changed, 0 insertions, 0 deletions