Merge pull request #92 from lucascolley/array-api-strict

MAINT: replace `numpy.array_api` references with `array_api_strict`

README.md

@@ -71,23 +71,24 @@ namespace, except that functions that are part of the array API are wrapped so
 that they have the correct array API behavior. In each case, the array object
 used will be the same array object from the wrapped library.
 
-## Difference between `array_api_compat` and `numpy.array_api`
+## Difference between `array_api_compat` and `array_api_strict`
 
-`numpy.array_api` is a strict minimal implementation of the Array API (see
+`array_api_strict` is a strict minimal implementation of the array API standard, formerly
+known as `numpy.array_api` (see
 [NEP 47](https://numpy.org/neps/nep-0047-array-api-standard.html)). For
-example, `numpy.array_api` does not include any functions that are not part of
+example, `array_api_strict` does not include any functions that are not part of
 the array API specification, and will explicitly disallow behaviors that are
 not required by the spec (e.g., [cross-kind type
 promotions](https://data-apis.org/array-api/latest/API_specification/type_promotion.html)).
-(`cupy.array_api` is similar to `numpy.array_api`)
+(`cupy.array_api` is similar to `array_api_strict`)
 
 `array_api_compat`, on the other hand, is just an extension of the
 corresponding array library namespaces with changes needed to be compliant
 with the array API. It includes all additional library functions not mentioned
 in the spec, and allows any library behaviors not explicitly disallowed by it,
 such as cross-kind casting.
 
-In particular, unlike `numpy.array_api`, this package does not use a separate
+In particular, unlike `array_api_strict`, this package does not use a separate
 `Array` object, but rather just uses the corresponding array library array
 objects (`numpy.ndarray`, `cupy.ndarray`, `torch.Tensor`, etc.) directly. This
 is because those are the objects that are going to be passed as inputs to
@@ -96,7 +97,7 @@ functions by end users. This does mean that a few behaviors cannot be wrapped
 most things.
 
 Array consuming library authors coding against the array API may wish to test
-against `numpy.array_api` to ensure they are not using functionality outside
+against `array_api_strict` to ensure they are not using functionality outside
 of the standard, but prefer this implementation for the default behavior for
 end-users.
 

array_api_compat/__init__.py

@@ -5,14 +5,14 @@
 Array API standard https://data-apis.org/array-api/latest/. See also NEP 47
 https://numpy.org/neps/nep-0047-array-api-standard.html.
 
-Unlike numpy.array_api, this is not a strict minimal implementation of the
+Unlike array_api_strict, this is not a strict minimal implementation of the
 Array API, but rather just an extension of the main NumPy namespace with
 changes needed to be compliant with the Array API. See
 https://numpy.org/doc/stable/reference/array_api.html for a full list of
-changes. In particular, unlike numpy.array_api, this package does not use a
+changes. In particular, unlike array_api_strict, this package does not use a
 separate Array object, but rather just uses numpy.ndarray directly.
 
-Library authors using the Array API may wish to test against numpy.array_api
+Library authors using the Array API may wish to test against array_api_strict
 to ensure they are not using functionality outside of the standard, but prefer
 this implementation for the default when working with NumPy arrays.
 

array_api_compat/common/_aliases.py

@@ -543,5 +543,5 @@ def isdtype(
         # This will allow things that aren't required by the spec, like
         # isdtype(np.float64, float) or isdtype(np.int64, 'l'). Should we be
         # more strict here to match the type annotation? Note that the
-        # numpy.array_api implementation will be very strict.
+        # array_api_strict implementation will be very strict.
         return dtype == kind