Skip to content

DOC - adding dev documentation about the dataframe API and df_module - #2253

Draft
rcap107 wants to merge 6 commits into
skrub-data:mainfrom
rcap107:dev-docs-dispatch-df_module
Draft

DOC - adding dev documentation about the dataframe API and df_module#2253
rcap107 wants to merge 6 commits into
skrub-data:mainfrom
rcap107:dev-docs-dispatch-df_module

Conversation

@rcap107

@rcap107 rcap107 commented Aug 26, 2026

Copy link
Copy Markdown
Member

This PR is adding documentation about the dispatched dataframe API and the df_module and testing framework.

For the moment, they have not been added to the rendered documentation, so they're only available from inside the repository. We can decide to put them on the website if needed.

I asked an agent to generate the bulk of the material, then I reviewed it to remove/rephrase some of the content. I'll leave this in draft mode to get a few more eyes on and trim it more if necessary.

@rcap107

rcap107 commented Aug 26, 2026

Copy link
Copy Markdown
Member Author

Somewhat unrelated, we currently don't have a dedicated place that we use to keep developer-specific documentation, so we might want to rework a bit the material so that the new contributor guide and the release guide are in the same place as the pages added in this PR, though that can be in a separate PR.


``df_module`` solves a different problem: when a test needs to construct
inputs, call a function, and check the output, it must do so in a way that
works for all three configurations. ``df_module`` provides a uniform

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

configurations is sort of vague here. maybe something about the 3 supported dataframe types?

It specifies it further below but I think it could be moved up to make it clearer.

itself is backend-specific.

The design principle is the same in both cases: write the general case once
and isolate backend differences to dedicated, clearly labelled places.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Suggested change
and isolate backend differences to dedicated, clearly labelled places.
and isolate backend differences to dedicated, clearly labeled places.


skrub targets both pandas and polars as first-class backends. Rather than
scattering ``if pandas … else polars …`` branches throughout the codebase, all
dataframe and column operations are funnelled through a thin dispatch layer that

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Suggested change
dataframe and column operations are funnelled through a thin dispatch layer that
dataframe and column operations are funneled through a thin dispatch layer that

``df_module`` is defined in ``skrub/conftest.py`` and returns a
:class:`types.SimpleNamespace` with a consistent set of attributes. The
attributes are designed to normalise the differences between libraries so test
bodies need no ``if pandas / if polars`` branches (with few exceptions).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Suggested change
bodies need no ``if pandas / if polars`` branches (with few exceptions).
bodies need no ``if pandas / if polars`` branches (with a few exceptions).

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants