Supporting duck array coercion
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 32.8k
- Forks
- 12.8k
- Avg merge
- 1d 7h
- Merged PRs (30d)
- 197
Description
Opening this issue after some discussion with @shoyer, @pentschev, and @mrocklin in issue ( https://github.com/dask/dask/issues/4883 ). AIUI this was discussed in NEP 22 (so I'm mainly parroting other people's ideas here to renew discussion and correct my own misunderstanding ;).
It would be useful for various downstream array libraries to have a function to ensure we have some duck array (like ndarray). This would be somewhat similar to np.asanyarray, but without the requirement of subclassing. It would allow libraries to return their own (duck) array type. If no suitable conversion was supported by the object, we could fallback to handle ndarray subclasses, ndarrays, and coercion of other things (nested lists) to ndarrays.
cc @njsmith (who coauthored NEP 22)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the discussion in NumPy issue #4883 and NEP 22, especially the section on protocols, then compare the proposed coercion behavior with existing NumPy array-conversion APIs. The issue does not name implementation files or tests; done would require an agreed design and corresponding behavior for duck arrays, ndarray subclasses, ndarrays, and nested inputs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- data
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100