BUG: DataFrame.update changes type of updated values

[guziy]

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

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

• (optional) I have confirmed this bug exists on the master branch of pandas.

---

Note: Please read this guide detailing how to provide the necessary information for us to reproduce your bug.

Code Sample, a copy-pastable example

import pandas as pd
df1 = pd.DataFrame.from_dict({"A": [1, 2, 3]})
df2 = pd.DataFrame.from_dict({"A": [4,  5]})
print(df1["A"])
df1.update(df2)
print(df1["A"])

Output:

# df1 before the update
0    1
1    2
2    3
Name: A, dtype: int64

# df1 after the update
0    4.0
1    5.0
2    3.0
Name: A, dtype: float64

Problem description

Update of int columns changes their type to float, that is unexpected behavior. And this happens only if the other dataframe does not have all indices of this dataframe. I would expect the type to be conserved...

Expected Output

Output of pd.show_versions()

INSTALLED VERSIONS

commit : 2cb9652
python : 3.8.1.final.0
python-bits : 64
OS : Linux
OS-release : 3.10.0-957.el7.x86_64
Version : #1 SMP Thu Oct 4 20:48:51 UTC 2018
machine : x86_64
processor : x86_64
byteorder : little
LC_ALL : None
LANG : None
LOCALE : en_US.UTF-8

pandas : 1.2.4
numpy : 1.19.5
pytz : 2021.1
dateutil : 2.8.1
pip : 21.0.1
setuptools : 49.6.0.post20210108
Cython : 0.29.15
pytest : 5.3.5
hypothesis : None
sphinx : 3.4.3
blosc : None
feather : None
xlsxwriter : None
lxml.etree : 4.5.0
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : 3.0.1
IPython : 7.12.0
pandas_datareader: None
bs4 : 4.8.2
bottleneck : 1.3.2
fsspec : 2021.06.0
fastparquet : None
gcsfs : None
matplotlib : 3.4.2
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyxlsb : None
s3fs : None
scipy : 1.5.2
sqlalchemy : None
tables : None
tabulate : None
xarray : 0.16.2
xlrd : None
xlwt : None
numba : None
1
​

[mzeitlin11]

Thanks for reporting this @guziy! Looks like a duplicate of #4094 for which there is a stalled pr at #40219 that would fix this case.

[guziy]

I did look for a duplicate in open issues but, there were too many results and I probably missed it. Not sure if this issue being open would help to advance the pull request. Please let me know if you want this to be closed.

[mzeitlin11]

there were too many results

There are a lot :)

Not sure if this issue being open would help to advance the pull request.

I had the same question which is why I added the closing candidate label but didn't close. Maybe a more recent issue would make it likelier someone picks up the PR

[mroeschke]

Closing as a duplicate of #4094