pandas 3.1 breaking changes: what changes your data today, and what only warns

pandas 3.1.0 shipped on October 22, 2026, and the pandas 3.1 breaking changes worth your attention are not the loud one. The deprecation of `inplace=` touches eleven everyday methods and breaks nothing until pandas 4.0. A smaller set of changes can alter your results or stop the install, the moment you bump the pin.

Everything below is read from the pandas documentation on October 23, 2026, the day after the release. Release notes get corrected, so check the version you are installing.

The pandas 3.1 breaking changes that change results, not just warnings

Each of these produces different output rather than a warning, and one of them is silent.

The category one is the change we would check first, because nothing warns you. The release notes say plainly that "identifier-like columns are the main thing to watch for: a column of zero-padded account numbers or zip codes now gets integer categories, dropping the leading zeros exactly as it does without `dtype="category"`." If a pipeline reads customer IDs, SKUs or postal codes with `dtype="category"` for memory, that column changes meaning without failing a test that only checks row counts.

One more item in the 3.1 notes is worth reading even if you never touch the API: pandas no longer uses `numexpr` 2.14.1, because "some builds of that release intermittently and silently returned incorrect results." That guard is new in 3.1, so if that numexpr build sits in your current environment, the version you have pinned is worth a look before you blame pandas for anything.

Is inplace deprecated in pandas 3.1? Yes, on methods that never worked in place

The 3.1 release notes deprecate the `inplace` keyword "for all methods that do not actually work 'inplace'" - eleven DataFrame and Series methods: `drop()`, `rename()`, `rename_axis()`, `reset_index()`, `set_index()`, `dropna()`, `drop_duplicates()`, `sort_values()`, `sort_index()`, `eval()` and `query()`. The replacement is reassignment: `df = df.reset_index()`.

Methods that genuinely mutate values keep the keyword. The notes name `fillna()` and `replace()` as examples that "can actually update the underlying values," so those are not part of this change.

Nothing stops working. pandas' version policy states that "if a behavior is deprecated in pandas 3.1.0, it will continue to work, with a warning, for all releases in the 3.x series," and that deprecations "will only be enforced in major releases" - here, 4.0.0.

You may not even see the warning. Under the same policy, a new deprecation first emits `PandasDeprecationWarning`, and "by default, Python hides `DeprecationWarning` outside the `__main__` module, so end users typically will not see these warnings unless they explicitly opt in." It is promoted to `PandasFutureWarning`, which Python shows by default, only "in the final minor release before the next major version." Separately, the lossy `.values` behavior for timezone-aware, period and interval dtypes now "emits a `Pandas4Warning`" - the documented class for changes that will be enforced in 4.0.

In our view that quiet period is the reason to act now rather than later: the `inplace` rewrite is mechanical, every call site is findable by grep, and doing it while a warning is the penalty is cheaper than doing it when the import fails. Turning pandas' change warnings into errors in CI is how you find the call sites your tests actually exercise. If you would rather not hand-edit hundreds of call sites, this is the narrow, verifiable kind of job the free AI coding assistants we compared in 2026 are good at - Upfynd lists 121 tools in AI Coding Tools as of October 2026, among them Cursor - but review the diff, because a blind find-and-replace will also rewrite the `fillna()` calls that should keep the keyword.

What can block the upgrade outright

Three things in 3.1 are not deprecations and not negotiable.

• NumPy 1.x is out. The notes state that "support for NumPy 1.26 (and 1.x in general) has been dropped, and pandas now requires NumPy >= 2.0.2." If anything else in your environment pins NumPy below 2, pandas 3.1 does not go in.
• HDF5 writes are forward-only. `DataFrame.to_hdf()` stopped writing the `pandas_version` attribute, and as a consequence `format="table"` files written with pandas 3.1 "cannot be read by pandas 3.0 or earlier." If one service writes and another reads, upgrade both or neither.
• `select_dtypes` is stricter. It now matches resolutions and dtype instances more strictly and raises on some specifications that used to be accepted.

The `fastparquet` engine and the `mode.chained_assignment` option are deprecated in 3.1 as well - the second a leftover from the Copy-on-Write work, which already has no effect in 3.x.

read_csv is two to three times faster, and parallel by default

In our view this is the reason to want 3.1. A single-threaded read with the default `engine="c"` is "typically two to three times faster than in 3.0," and on top of that, "large files are now read in parallel across several CPU cores."

The parallel path is narrow and conservative. It applies when the input is "a local, uncompressed file of at least 5 MB and no options are passed that require parsing the file as a whole," and the notes state that "the result is identical to a serial read." Thread count comes from the new `mode.max_threads` option, which defaults to the number of CPUs available to the process, "capped at 6."

Set it to 1 if pandas runs inside something that already parallelizes - a worker per file, a Spark or Dask task, a request handler. That is the case the option exists for, and we would treat it as the one place in this release where a faster default can make your throughput worse.

Who has to act this week, and who can wait

• Still on pandas 2.x: your real migration is 3.0, not 3.1. The 3.0 release made the `str` dtype the default and Copy-on-Write the only mode, which means chained assignment such as `df["foo"][df["bar"] > 5] = 100` stops working. The migration guides cover both, and you can preview the string behavior on 2.3 with `pd.options.future.infer_string = True`.
• On 3.0.x and reading CSVs with `dtype="category"`: check your identifier columns before you upgrade. 3.0.6, from September 17, 2026, is where the 3.0 line stands.
• Writing HDF5 for other services: coordinate the upgrade, or keep writing from 3.0.
• Pinned to NumPy 1.x: that is the upgrade you have to do first.
• Warning-clean CI, NumPy 2, no HDF5, no category reads: this is an ordinary minor upgrade, and you get the faster reader.

The practical next step is one test run, not a plan: install 3.1 in a scratch environment, run the suite with pandas' change warnings raised as errors, and grep for `dtype="category"` and `to_hdf` while that runs. The libraries and platforms around pandas move on their own schedule - Upfynd lists 163 tools in Data Science as of October 2026, Databricks among them, with app layers such as Streamlit alongside - so check their supported pandas range on their own docs before you upgrade the environment they run in. If you maintain one of them, you can list it on Upfynd for free.