← Home

Data tools

The pandas 3 Change That Will Break Your Code Does Not Warn You

Everyone is fixing SettingWithCopyWarning. That one never worked anyway. The write that works today and silently stops working under Copy-on-Write does not emit a warning in either version.

The pandas 3 migration advice you will find is mostly about SettingWithCopyWarning. That is the wrong thing to be worried about, and it is worth being precise about why: the code that warning fires on never worked. Fixing it changes nothing about your results.

The code that did work, and stops, is silent in both directions.

The one that matters

Measured on pandas 2.3.3 (Python 3.9.6):

df = pd.DataFrame({"a": [1, 2, 3], "b": [10, 20, 30]})
col = df["a"]
col.iloc[0] = 99
df["a"].tolist()

The value goes from 99 to 1. Neither version says a single word about it.

That is the whole problem. Running your test suite with -W error::FutureWarning — the standard advice for a pandas migration — will not surface this, because there is no warning to raise.

Compare them yourself

col = df["a"]
col.iloc[0] = 99
df["a"].tolist()

Six patterns, each run under both defaults, results and warnings recorded verbatim. Of the six, exactly one changes result with no warning on either side.

Why the famous warning is the wrong target

Chained assignment produces the same result under both defaults:

df[df.a > 1]["b"] = 0
# pandas 2: [10, 20, 30]   SettingWithCopyWarning
# pandas 3: [10, 20, 30]   ChainedAssignmentError

It did not update the DataFrame before, and it does not now. What improved is the honesty of the message. pandas 2 says the object may be a copy; Copy-on-Write says it never works, because the intermediate object always behaves as a copy.

That is a real upgrade — a maybe became a guarantee — but it is a documentation improvement, not a behaviour change. Your results were already whatever they were.

The inplace case is halfway

df["a"].fillna(0, inplace=True)

This one does change result — [1.0, 0.0, 3.0] becomes [1.0, nan, 3.0] — but pandas 2 warns about it, and the warning finishes the thought:

The behavior will change in pandas 3.0. This inplace method will never work because the intermediate object on which we are setting values always behaves as a copy.

It even hands you the fix: df.method({col: value}, inplace=True). So this one is findable before you upgrade. Good.

What not to change

Two of the six are stable, and knowing that saves work:

df.loc[df.a > 1, "b"] = 0        # identical under both, no warnings
renamed = df.rename(...)          # already returned a copy; nothing changes

The single-step .loc form is the target to convert to. It is not a workaround — it is the form whose behaviour does not depend on which pandas you are running.

How to actually find these

Not with a warning filter. With the flag:

pd.options.mode.copy_on_write = True

That option in pandas 2 is the pandas 3 behaviour. Turn it on, run your test suite, and anything that fails is something the upgrade would have broken later, quietly, in production. It costs one line and one test run.

The deprecation warnings still deserve a pass — applymap, fillna(method=...), the replace downcasting warning, groupby().apply() on grouping columns — and those are genuinely easy: they announce themselves, so one run with warnings raised as errors finds every occurrence.

But they are the half you were already going to find. Spend the afternoon on the half that does not tell you.