Description
This RFC proposes to add an API to the standard for returning the list of currently supported dtypes. Currently, in order to query dtype support, one must do something like
hasattr(xp, "uint32")and do so for each dtype specified in the array API standard. This is less than ideal, especially when testing. Additionally, this approach only works for known (i.e., specified) dtypes. One lacks a universal mechanism for dtype inspection (e.g., in a REPL). This RFC proposes to rectify this gap.
Prior art
To my knowledge, none of NumPy, JAX, PyTorch, TensorFlow, Dask, or MXNet support a common API for querying supported dtypes.
Proposal
dtypes() -> List[dtype]
dtypes(device: device) -> List[dtype]If not provided an argument, the proposed API would return a list of currently supported dtype objects.
If provided a device, the proposed API would return a list of supported dtype objects applicable to the specified device.
Notes
-
When the proposed API is invoked without an argument, the list of currently supported dtypes would be based on the current device context. As discussed in the standard
...it is possible that a library supports multiple devices, with not all those device types supporting the same data types.
For libraries supporting a single device (e.g., currently NumPy and CPU),
dtypes()would always return the same list. For libraries supporting multiple devices, the list of dtypes returned bydtypes()could vary.For downstream users, they should be advised to not assume that
dtypes()always returns the same list, especially when designing APIs intended to be array library agnostic.