Skip to content

Commit d5f252b

Browse files
authored
Describe what extensions are and how to use themo (#470)
Note that an alternative idea discussed earlier was a separate function `get_extension()`, but IIRC that was not considered a good idea. Now that we have module-level `__getattr__`'s, it should not be a problem for any library to use a specified name like `linalg` or `fft`. Whether the functions in the `linalg` extensions should all be required to exist or not was discussed in gh-403 (no clear conclusion there). One option discussed there to deal with hard to implement or more niche APIs is to create a separate status/label or some other way to track desired signatures (details to be worked out if we want to go that way).
1 parent 177675c commit d5f252b

File tree

2 files changed

+40
-2
lines changed

2 files changed

+40
-2
lines changed

spec/extensions/index.rst

+23-2
Original file line numberDiff line numberDiff line change
@@ -3,9 +3,30 @@
33
Extensions
44
==========
55

6+
Extensions are coherent sets of functionality that are commonly implemented
7+
across array libraries. Each array library supporting this standard may, but is
8+
not required to, implement an extension. If an extension is supported, it
9+
must be accessible inside the main array API supporting namespace as a separate
10+
namespace.
11+
12+
Extension module implementors must aim to provide all functions and other
13+
public objects in an extension. The rationale for this is that downstream usage
14+
can then check whether or not the extension is present (using ``hasattr(xp,
15+
'extension_name')`` should be enough), and can then assume that functions are
16+
implemented. This in turn makes it also easy for array-consuming libraries to
17+
document which array libraries they support - e.g., "all libraries implementing
18+
the array API standard and its linear algebra extension".
19+
20+
The mechanism through which the extension namespace is made available is up to
21+
the implementer, e.g. via a regular submodule that is imported under the
22+
``linalg`` name, or via a module-level ``__getattr__``.
23+
24+
25+
Extensions
26+
----------
27+
628
.. toctree::
7-
:caption: Extensions
8-
:maxdepth: 3
29+
:maxdepth: 1
930

1031
fourier_transform_functions
1132
linear_algebra_functions

spec/extensions/linear_algebra_functions.rst

+17
Original file line numberDiff line numberDiff line change
@@ -5,6 +5,23 @@ Linear Algebra Extension
55

66
Array API specification for linear algebra functions.
77

8+
Extension name and usage
9+
------------------------
10+
11+
The name of the namespace providing the extension must be: ``linalg``.
12+
13+
If implemented, this ``linalg`` extension must be retrievable via::
14+
15+
>>> xp = x.__array_namespace__()
16+
>>> if hasattr(xp, 'linalg'):
17+
>>> # Use `xp.linalg`
18+
19+
20+
General syntax and semantics rules
21+
----------------------------------
22+
23+
.. TODO: get rid of this here, it's duplicated over and over
24+
825
A conforming implementation of the array API standard must provide and support the following functions adhering to the following conventions.
926

1027
- Positional parameters must be `positional-only <https://www.python.org/dev/peps/pep-0570/>`_ parameters. Positional-only parameters have no externally-usable name. When a function accepting positional-only parameters is called, positional arguments are mapped to these parameters based solely on their order.

0 commit comments

Comments
 (0)