Skip to content

Support pandas 3 for DataFrame XComs - #70558

Open
potiuk wants to merge 3 commits into
mainfrom
pandas-3-support
Open

Support pandas 3 for DataFrame XComs#70558
potiuk wants to merge 3 commits into
mainfrom
pandas-3-support

Conversation

@potiuk

@potiuk potiuk commented Jul 27, 2026

Copy link
Copy Markdown
Member

pandas 3 exposes its public classes from the pandas namespace, so a DataFrame is qualified as pandas.DataFrame rather than pandas.core.frame.DataFrame. The serde registry is keyed on that name and only knew the old one, so under pandas 3 no DataFrame could be pushed through XCom at all:

TypeError: cannot serialize object of type <class 'pandas.DataFrame'>

Both names are now registered, so a DataFrame written by either pandas version can be read by either. Verified across all four combinations (writer x reader), with the payload written by one interpreter and read by the other:

Reader pandas-2 payload pandas-3 payload
pandas 2.3.3 object, missing = None object, missing = None
pandas 3.0.5 str, missing = nan str, missing = nan

The reader's pandas version decides the dtypes, not the writer's — that, and the fact that a component without this change cannot read a pandas-3-written DataFrame XCom, is what the significant newsfragment documents.

Two provider tests also asserted on pandas 2 behaviour (object dtype, missing values stringified to "nan" / "None") and are now version-aware. The production paths were already correct.

Split out of #70501, which holds the development environment on pandas 2 in the meantime.


Was generative AI tooling used to co-author this PR?
  • Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

potiuk added 3 commits July 28, 2026 09:34
pandas 3 exposes its public classes from the `pandas` namespace, so a
DataFrame is now qualified as `pandas.DataFrame` rather than
`pandas.core.frame.DataFrame`. The serializer was registered only under the
old name, so pushing a DataFrame through XCom raised "cannot serialize
object of type <class 'pandas.DataFrame'>". Both names are registered so
values written by either version stay readable.

pandas 3 also infers a str column where it used to infer object, and keeps
its missing values as NA instead of stringifying them, which the amazon and
salesforce tests asserted on.
Deployments need to know that every component has to carry the pandas 3
support before pandas 3 reaches any worker, that a rollback strands the
XComs written in the meantime, and that a pulled DataFrame now takes its
dtypes from the reader's pandas version.
@potiuk
potiuk force-pushed the pandas-3-support branch from 4adc020 to 0779e0a Compare July 28, 2026 07:34
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.

1 participant