summaryrefslogtreecommitdiff
path: root/numpy/array_api/_array_object.py
diff options
context:
space:
mode:
authorBas van Beek <43369155+BvB93@users.noreply.github.com>2022-09-07 09:22:54 +0200
committerGitHub <noreply@github.com>2022-09-07 09:22:54 +0200
commit7a17d01977e5e6a9b7ef8f4c435235e711bc97be (patch)
tree1f0f0f5e61f21b2366393d7d266082992ed2c5cf /numpy/array_api/_array_object.py
parent5bc59763e891ab367410085453c352198cb935d4 (diff)
downloadnumpy-7a17d01977e5e6a9b7ef8f4c435235e711bc97be.tar.gz
TYP,BUG: Reduce argument validation in C-based `__class_getitem__` (#22212)
Closes #22185 The __class_getitem__ implementations would previously perform basic validation of the passed value, i.e. it would check whether a tuple of the appropriate length was passed (e.g. np.dtype.__class_getitem__ would expect a single item or a length-1 tuple). As noted in aforementioned issue: this approach can cause issues when (a. 2 or more parameters are involved and (b. a subclasses is created one or more parameters are declared constant (e.g. a fixed dtype & variably shaped array). This PR fixes aforementioned issue by relaxing the runtime argument validation, thus mimicking the behavior of the standard library (more closely). While we could alternatively fix this by adding more special casing (e.g. only disable validation when cls is not np.ndarray), I'm not convinced this would be worth the additional complexity, especially since the standard library also has zero runtime validation for all of its Py_GenericAlias-based implementations of __class_getitem__. (Some edits by seberg to the commit message)
Diffstat (limited to 'numpy/array_api/_array_object.py')
0 files changed, 0 insertions, 0 deletions