BUG: Data corruption after `.eval(..., inplace=True)`.

[VukanJ]

Pandas version checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• I have confirmed this bug exists on the main branch of pandas.

Reproducible Example

import numpy as np, pandas as pd
rng = np.random.default_rng(42)
nums = rng.choice([-1, 1], size=10_000).astype(np.int32)
df = pd.DataFrame({"nums": nums.copy()})
df.eval("nums2 = nums", inplace=True)
mask = rng.random(10_000) > 0.5
df.loc[mask, "nums2"] = 0
assert np.array_equal(df["nums"].to_numpy(), nums), "BUG: nums was corrupted!"

Issue Description

When using df.eval("new=old",inplace=True) to initialize a column with another column, no genuine copy is made, leading to data corruption when modifying column entries through df.loc. This affects pandas starting from 3.0.0 up to the latest version 3.0.3.

Expected Behavior

Assert should pass. Pandas should always create a data copy when initializing with df.eval("new=old", inplace=True). Writes to the new column through df.loc[] should not affect the source column.

Installed Versions

Details

INSTALLED VERSIONS

commit : 72f2fea
python : 3.11.14
python-bits : 64
OS : Linux
OS-release : 7.0.3-arch1-2
Version : #1 SMP PREEMPT_DYNAMIC Fri, 01 May 2026 15:49:22 +0000
machine : x86_64
processor :
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 3.0.3
numpy : 2.2.6
dateutil : 2.9.0.post0
pip : 26.0.1
Cython : None
sphinx : 9.0.4
IPython : 9.10.0
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : 4.14.3
bottleneck : None
fastparquet : None
fsspec : 2026.2.0
html5lib : None
hypothesis : None
gcsfs : None
jinja2 : 3.1.6
lxml.etree : None
matplotlib : 3.10.8
numba : 0.61.2
numexpr : None
odfpy : None
openpyxl : None
psycopg2 : None
pymysql : None
pyarrow : None
pyiceberg : None
pyreadstat : None
pytest : 9.0.2
python-calamine : None
pytz : 2025.2
pyxlsb : None
s3fs : None
scipy : 1.17.1
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
xlsxwriter : None
zstandard : None
qtpy : None
pyqt5 : None

[tanishapritha]

Thanks for the clear reproducer! The issue seems to be that eval(..., inplace=True) assigns the result without copying, leaving both columns backed by the same array. CoW's reference tracking doesn't catch the intra-DataFrame alias, so writing to nums2 corrupts nums.

I'd like to work on a fix for this if it's not already claimed. Would a maintainer be able to confirm and assign it to me?

[rahulrathnavel]

Hi @tanishapritha! I see you expressed interest in taking this on. If you haven't started yet or end up being too busy, I would love to give this a try as my very first open-source contribution to pandas. If you are already working on it though, no worries at all and good luck with the fix!
@VukanJ want yours appeal too!

[GiTaDi-CrEaTe]

Hey @VukanJ, thank you for providing such a clean and precise reproducer. It made isolating the memory leak much easier.

@tanishapritha / @rahulrathnavel — you both had the exact right intuition regarding the CoW tracking bypass. I was already deep in the pandas.core.computation engine testing some memory safety boundaries and had a patch ready for this, so I went ahead and pushed it through in #65675

For the maintainers: The issue stems from the eval engine stripping the tracking metadata before handing the raw memory back to the DataFrame. I've submitted a PR that intercepts the evaluated result and forces an explicit .copy() if inplace=True before assignment, which perfectly seals the CoW perimeter and passes the reproducer.