Update the module docstring

Author: asmeurer

array_api_strict/__init__.py

@@ -1,117 +1,18 @@
 """
-A NumPy sub-namespace that conforms to the Python array API standard.
-
-This submodule accompanies NEP 47, which proposes its inclusion in NumPy. It
-is still considered experimental, and will issue a warning when imported.
-
-This is a proof-of-concept namespace that wraps the corresponding NumPy
-functions to give a conforming implementation of the Python array API standard
-(https://data-apis.github.io/array-api/latest/). The standard is currently in
-an RFC phase and comments on it are both welcome and encouraged. Comments
-should be made either at https://github.com/data-apis/array-api or at
-https://github.com/data-apis/consortium-feedback/discussions.
-
-NumPy already follows the proposed spec for the most part, so this module
-serves mostly as a thin wrapper around it. However, NumPy also implements a
-lot of behavior that is not included in the spec, so this serves as a
-restricted subset of the API. Only those functions that are part of the spec
-are included in this namespace, and all functions are given with the exact
-signature given in the spec, including the use of position-only arguments, and
-omitting any extra keyword arguments implemented by NumPy but not part of the
-spec. The behavior of some functions is also modified from the NumPy behavior
-to conform to the standard. Note that the underlying array object itself is
-wrapped in a wrapper Array() class, but is otherwise unchanged. This submodule
-is implemented in pure Python with no C extensions.
-
-The array API spec is designed as a "minimal API subset" and explicitly allows
-libraries to include behaviors not specified by it. But users of this module
-that intend to write portable code should be aware that only those behaviors
-that are listed in the spec are guaranteed to be implemented across libraries.
-Consequently, the NumPy implementation was chosen to be both conforming and
-minimal, so that users can use this implementation of the array API namespace
-and be sure that behaviors that it defines will be available in conforming
-namespaces from other libraries.
-
-A few notes about the current state of this submodule:
-
-- There is a test suite that tests modules against the array API standard at
-  https://github.com/data-apis/array-api-tests. The test suite is still a work
-  in progress, but the existing tests pass on this module, with a few
-  exceptions:
-
-  - DLPack support (see https://github.com/data-apis/array-api/pull/106) is
-    not included here, as it requires a full implementation in NumPy proper
-    first.
-
-  The test suite is not yet complete, and even the tests that exist are not
-  guaranteed to give a comprehensive coverage of the spec. Therefore, when
-  reviewing and using this submodule, you should refer to the standard
-  documents themselves. There are some tests in array_api_strict.tests, but
-  they primarily focus on things that are not tested by the official array API
-  test suite.
-
-- There is a custom array object, array_api_strict.Array, which is returned by
-  all functions in this module. All functions in the array API namespace
-  implicitly assume that they will only receive this object as input. The only
-  way to create instances of this object is to use one of the array creation
-  functions. It does not have a public constructor on the object itself. The
-  object is a small wrapper class around numpy.ndarray. The main purpose of it
-  is to restrict the namespace of the array object to only those dtypes and
-  only those methods that are required by the spec, as well as to limit/change
-  certain behavior that differs in the spec. In particular:
-
-  - The array API namespace does not have scalar objects, only 0-D arrays.
-    Operations on Array that would create a scalar in NumPy create a 0-D
-    array.
-
-  - Indexing: Only a subset of indices supported by NumPy are required by the
-    spec. The Array object restricts indexing to only allow those types of
-    indices that are required by the spec. See the docstring of the
-    array_api_strict.Array._validate_indices helper function for more
-    information.
-
-  - Type promotion: Some type promotion rules are different in the spec. In
-    particular, the spec does not have any value-based casting. The spec also
-    does not require cross-kind casting, like integer -> floating-point. Only
-    those promotions that are explicitly required by the array API
-    specification are allowed in this module. See NEP 47 for more info.
-
-  - Functions do not automatically call asarray() on their input, and will not
-    work if the input type is not Array. The exception is array creation
-    functions, and Python operators on the Array object, which accept Python
-    scalars of the same type as the array dtype.
-
-- All functions include type annotations, corresponding to those given in the
-  spec (see _typing.py for definitions of some custom types). These do not
-  currently fully pass mypy due to some limitations in mypy.
-
-- Dtype objects are just the NumPy dtype objects, e.g., float64 =
-  np.dtype('float64'). The spec does not require any behavior on these dtype
-  objects other than that they be accessible by name and be comparable by
-  equality, but it was considered too much extra complexity to create custom
-  objects to represent dtypes.
-
-- All places where the implementations in this submodule are known to deviate
-  from their corresponding functions in NumPy are marked with "# Note:"
-  comments.
-
-Still TODO in this module are:
-
-- DLPack support for numpy.ndarray is still in progress. See
-  https://github.com/numpy/numpy/pull/19083.
-
-- The copy=False keyword argument to asarray() is not yet implemented. This
-  requires support in numpy.asarray() first.
-
-- Some functions are not yet fully tested in the array API test suite, and may
-  require updates that are not yet known until the tests are written.
-
-- The spec is still in an RFC phase and may still have minor updates, which
-  will need to be reflected here.
-
-- Complex number support in array API spec is planned but not yet finalized,
-  as are the fft extension and certain linear algebra functions such as eig
-  that require complex dtypes.
+array_api_strict is a strict, minimal implementation of the Python array
+API (https://data-apis.org/array-api/latest/)
+
+The purpose of array-api-strict is to provide an implementation of the array
+API for consuming libraries to test against so they can be completely sure
+their usage of the array API is portable.
+
+It is *not* intended to be used by end-users. End-users of the array API
+should just use their favorite array library (NumPy, CuPy, PyTorch, etc.) as
+usual. It is also not intended to be used as a dependency by consuming
+libraries. Consuming library code should use the
+array-api-compat (https://github.com/data-apis/array-api-compat) package to
+support the array API. Rather, it is intended to be used in the test suites of
+consuming libraries to test their array API usage.
 
 """