@@ -66,7 +66,9 @@ def __hash__(self):
66
66
67
67
_default = object ()
68
68
69
- _allow_array = False
69
+ # See https://github.com/data-apis/array-api-strict/issues/67 and the comment
70
+ # on __array__ below.
71
+ _allow_array = True
70
72
71
73
class Array :
72
74
"""
@@ -147,15 +149,18 @@ def __repr__(self: Array, /) -> str:
147
149
mid = np .array2string (self ._array , separator = ', ' , prefix = prefix , suffix = suffix )
148
150
return prefix + mid + suffix
149
151
150
- # Disallow __array__, meaning calling `np.func()` on an array_api_strict
151
- # array will give an error. If we don't explicitly disallow it, NumPy
152
- # defaults to creating an object dtype array, which would lead to
153
- # confusing error messages at best and surprising bugs at worst.
154
- #
155
- # The alternative of course is to just support __array__, which is what we
156
- # used to do. But this isn't actually supported by the standard, so it can
152
+ # In the future, _allow_array will be set to False, which will disallow
153
+ # __array__. This means calling `np.func()` on an array_api_strict array
154
+ # will give an error. If we don't explicitly disallow it, NumPy defaults
155
+ # to creating an object dtype array, which would lead to confusing error
156
+ # messages at best and surprising bugs at worst. The reason for doing this
157
+ # is that __array__ is not actually supported by the standard, so it can
157
158
# lead to code assuming np.asarray(other_array) would always work in the
158
159
# standard.
160
+ #
161
+ # This was implemented historically for compatibility, and removing it has
162
+ # caused issues for some libraries (see
163
+ # https://github.com/data-apis/array-api-strict/issues/67).
159
164
def __array__ (self , dtype : None | np .dtype [Any ] = None , copy : None | bool = None ) -> npt .NDArray [Any ]:
160
165
# We have to allow this to be internally enabled as there's no other
161
166
# easy way to parse a list of Array objects in asarray().
0 commit comments