Array API compatibility #67
Assignees
Milestone
Comments
paddyroddy
added a commit
that referenced
this issue
Oct 4, 2024
Closes #198. For Array API support (#67), we need minimum versions of: 1. `Python 3.9` as specified here https://data-apis.org/array-api-compat/changelog.html#id9 2. `NumPy 1.22` as specified here https://numpy.org/doc/stable/reference/array_api.html#array-api-standard-compatibility In this PR I have enforced both of these. The code changes have come from `ruff` linting, utilising the benefits from [3.9](https://docs.python.org/3/whatsnew/3.9.html). I also removed some of the overzealous comments on imports. They weren't adding anything and meant the imports took up more room.
paddyroddy
added a commit
that referenced
this issue
Oct 15, 2024
Adding `mypy` to a pre-existing codebase is never easy. I initially attempted this in #308, but have since split this up into separate issues: - [x] #347 - [x] #356 - [ ] #358 In this PR, `mypy` is added but in order for CI to pass, the `# type: ignore[]` syntax is used throughout. I didn't want to tackle these here too (see #308) as it gets quite messy. One thing I have done (following #356) is change every empty `npt.NDArray` to `npt.NDArray[typing.Any]` (see #330), as this actually results in fewer errors than leaving them all blank. Ideally, we'd like to fill in as many of the `typing.Any` as possible - they're a bit useless by themselves. However, that is not the priority for now. Plus, I expect typing to change when #67 is tackled.
This was referenced Oct 24, 2024
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As much as possible of the core library should be made to work with compatible array types (numpy, torch, jax, dask, cupy, ...).
There is a nascent standard to support this: Array API
For the time being, the array-api-compat library can be used to get a universal namespace that replaces
np,jnp, etc.The text was updated successfully, but these errors were encountered: