Skip to content

Migration guide post-merge review#1000

Open
mtsokol wants to merge 2 commits intodata-apis:mainfrom
mtsokol:migration-guide-review
Open

Migration guide post-merge review#1000
mtsokol wants to merge 2 commits intodata-apis:mainfrom
mtsokol:migration-guide-review

Conversation

@mtsokol
Copy link
Copy Markdown
Contributor

@mtsokol mtsokol commented Mar 23, 2026

@lucascolley review of migration guide.

Copy link
Copy Markdown
Member

@lucascolley lucascolley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks Mateusz! A few more suggestions but this looks like a nice improvement!

@ev-br @kgryte did you want to take another look?

@lucascolley lucascolley added the Narrative Content Narrative documentation content. label Mar 23, 2026
@frazane
Copy link
Copy Markdown

frazane commented Mar 29, 2026

Hi @mtsokol, thanks for extending this migration guide, it's quite helpful. Just wondering about one thing - are there any guidelines on how to handle missing components of the array API standard? For instance, in my case I would love to see #725 addressed but I know it will take time. So in the meantime, is there any suggested approach on how I should extend the API in my own project?

@mtsokol
Copy link
Copy Markdown
Contributor Author

mtsokol commented Mar 30, 2026

Hi @frazane! Are you asking as an "array producer" standpoint? I believe reasonably anticipating what the API might look like once it (hopefully) lands would be the approach - nothing else comes to my mind. I see in the linked issue that for the special functions the discussion is already in an advanced state. Are you worrying that once you establish an API and the standard settles on something different then there's a churn of deprecating and communicating this to users?

FWIW noting in your docstrings/API docs page which functions are array API compatible (as a ::note or some badge) might help in the long term as well. Then if the standard embraces a different name/location/signature for the function, you add another one that is compatible, and deprecate the original one.

@frazane
Copy link
Copy Markdown

frazane commented Mar 31, 2026

Hi @mtsokol, no I am asking more from an array consumer standpoint. Very concretely, I want to be able to replace most of this with xp.

Still, the suggestion of trying to anticipate what the standard will look like is very reasonable. I suppose doing something along the lines of https://data-apis.org/array-api-extra/ also makes sense?

@lucascolley
Copy link
Copy Markdown
Member

For the special functions, I would say see how far you get calling SciPy. We delegate to PyTorch and JAX in quite a few places already, and have some fallback backend-agnostic implementations — see the ticks at https://scipy.github.io/devdocs/dev/api-dev/array_api_modules_tables/special.html#array-api-support-special-cpu.

For anything else you need that isn't available in the standard or array-api-extra, feel free to open an issue on array-api-extra and we can discuss how it could be made available!

@lucascolley
Copy link
Copy Markdown
Member

And feel free to open an issue on SciPy if there is any missing coverage for scipy.special that would be particularly useful for you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Narrative Content Narrative documentation content.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants