summaryrefslogtreecommitdiff
path: root/numpy/lib/function_base.py
diff options
context:
space:
mode:
authorSebastian Berg <sebastian@sipsolutions.net>2020-10-01 15:39:11 -0500
committerSebastian Berg <sebastian@sipsolutions.net>2020-10-01 15:53:07 -0500
commite31ae7ff70c72dec2cf7ba3bd817982ad1b68713 (patch)
tree2282a2e5964426c41909986c59fdea72ff290d8e /numpy/lib/function_base.py
parent57adb4bb6a8eb46fed597d4a781e47bcb86ebe11 (diff)
downloadnumpy-e31ae7ff70c72dec2cf7ba3bd817982ad1b68713.tar.gz
DEP: Deprecate coercion to subarray dtypes
When coercing to subarray dtypes, e.g. using `np.array(obj, dtype)`, but also `arr.astype(dtype)`, the behaviour was only well defined with tuple inputs, but not with array-like inputs. In particular, `arr.astype(dtype)` had arguably surprising behaviour of not converting by element, but rather attempting (and often failing) to broadcast `arr` to the result array with added dimensions. This deprecates all of these cases, the main issue would be for users relying on stranger inputs with broadcasted tuples contained in sequences: ``` np.array([((0, 1), (1, 2)), ((2,),)], dtype='(2,2)f4') ``` In most cases, where the tuples have the correct output shape, the new base dtype can be directly used since the discovered shape should match. However, there is no work-around for the above case. Closes gh-17173
Diffstat (limited to 'numpy/lib/function_base.py')
0 files changed, 0 insertions, 0 deletions