BUG: Assigning to a shallow copy did not change the original dataframe

[computbiolgeek]

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

df = pd.DataFrame({
    'A': [1, 2, 3],
    'B': [4, 5, 6]
})
shallow_copy = df.copy(deep=False)
shallow_copy['A'] = [4, 5, 6]
print(df)

Issue Description

Actual output was

   A  B
0  1  4
1  2  5
2  3  6

Expected Behavior

According to the documentation

When deep=False, a new object will be created without copying the calling object’s data or index (only references to the data and index are copied). Any changes to the data of the original will be reflected in the shallow copy (and vice versa).

If I am understanding it right, the expected output should be

   A  B
0  4  4
1  5  5
2  6  6

Installed Versions

INSTALLED VERSIONS

commit : e8093ba
python : 3.9.12.final.0
python-bits : 64
OS : Darwin
OS-release : 21.4.0
Version : Darwin Kernel Version 21.4.0: Fri Mar 18 00:46:32 PDT 2022; root:xnu-8020.101.4~15/RELEASE_ARM64_T6000
machine : arm64
processor : arm
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 1.4.3
numpy : 1.22.3
pytz : 2022.1
dateutil : 2.8.2
setuptools : 60.5.0
pip : 21.3.1
Cython : None
pytest : 7.1.2
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : 4.8.0
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : 3.0.3
IPython : 8.1.1
pandas_datareader: 0.10.0
bs4 : 4.10.0
bottleneck : None
brotli : 1.0.9
fastparquet : None
fsspec : None
gcsfs : None
markupsafe : 2.1.1
matplotlib : 3.5.2
numba : None
numexpr : None
odfpy : None
openpyxl : 3.0.10
pandas_gbq : None
pyarrow : 8.0.0
pyreadstat : None
pyxlsb : None
s3fs : None
scipy : 1.8.1
snappy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
xlwt : None
zstandard : None

[phofl]

Hi,

thanks for your report.
Setitem always makes a copy of the underlying array. Could you try with loc? Loc should work

[phofl]

Yep loc works, closing as usage question

[jorisvandenbossche]

@computbiolgeek As @phofl mentioned this is expected behaviour now, but it's certainly normal that you didn't expect that, as this was only changed in pandas 1.4. Code like df["A"] = ... (using __setitem__) now always creates a new column, and because it's a whole new column and not updating the values of the column in place, it no longer updates the parent dataframe.
See also the explanation at #45743 (comment) from a similar issue.

[computbiolgeek]

@phofl @jorisvandenbossche Thank you both for explaining! Maybe it would help to update the documentation in the next release?