summaryrefslogtreecommitdiff
path: root/numpy/array_api/tests/test_indexing_functions.py
diff options
context:
space:
mode:
authorSebastian Berg <sebastian@sipsolutions.net>2020-07-24 11:40:24 -0500
committerSebastian Berg <sebastian@sipsolutions.net>2020-07-24 11:40:24 -0500
commitd45b16dae51f9e8fa9b8296677e7a186b5efbc4a (patch)
treedaa6adc8ab52468a9a2dfee2f4f37c710b4b6ff9 /numpy/array_api/tests/test_indexing_functions.py
parent2d12d0c2f7ac7b5e79d95b958b4c75871029b9a6 (diff)
downloadnumpy-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