ENH: add consortium standard entrypoint #54383
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
No objections here. |
lithomas1
previously requested changes
Aug 3, 2023
lithomas1
reviewed
Aug 4, 2023
mroeschke
reviewed
Aug 4, 2023
mroeschke
reviewed
Aug 7, 2023
mroeschke
approved these changes
Aug 7, 2023
|
Thanks @MarcoGorelli |
mroeschke
pushed a commit
to mroeschke/pandas
that referenced
this pull request
Aug 18, 2023
* add consortium standard entrypoint * add dataframe-api-compat to optional dependencies, add to test_downstream * align * use importorskip * mypy * fixup table in docs * whatsnew * add check to package-checks.yml
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Here's an entry point to the Consortium's DataFrame API Standard
It enables dataframe-consuming libraries to just check for a
__dataframe_consortium_standard__attribute on a dataframe they receive - then, so long as they stick to the spec defined in https://data-apis.org/dataframe-api/draft/index.html, then their code should work the same way, regardless of what the original backing dataframe library wasUse-case: currently, scikit-learn is very keen on using this, as they're not keen on having to depend on pyarrow (which will become required in pandas), and the interchange protocol only goes so far (e.g. a way to convert to ndarray is out-of-scope for that). If we can get this to work there, then other use cases may emerge
The current spec should be enough for scikit-learn, and having this entry point makes it easier to move forwards with development (without monkey-patching / special-casing)
For reference, polars has already merged this: pola-rs/polars#10244
Maintenance burden on pandas
None
I want to be very clear about this: the compat package will be developed, maintained, and tested by the consortium and community of libraries which use it. It is up to consuming libraries to set a minimum version of the dataframe-api-compat package. No responsibility will land on pandas maintainers. If any bugs are reported to pandas, then they can (and should) be politely closed.
All this is just an entry point to the Consortium's Standard
Tagging @pandas-dev/pandas-core for visibility. Some people raised objections (maintenance burden, naming) when asked in private, and I think I've addressed the concerns. Anything else?
Thanks 🙌