BUG: df.iloc[:, x] = df.iloc[:, x].apply(int) will failed just and only when `int` in apply()

[tomy128]

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 pandas as pd
pd.__version__
# >>> '2.1.4'
df = pd.DataFrame(
    [[1.0],[2.0]]
    , columns=['A']
)
df.iloc[:, 0] = df.iloc[:, 0].apply(int)
df
# output below
#     A
# 0  1.0
# 1  2.0

# expected
#     A
# 0   1
# 1   2

Issue Description

FYI: df.iloc[:, 0] = df.iloc[:, 0].astype(int) failed too.

I tried pandas below pandas2.0, such as pandas 1.4.1 it worked expectly.

and during my tests, I found only the first time i put int or lambda x: int(x) in .apply() not working. other function will work properly.

Expected Behavior

# expected
#     A
# 0   1
# 1   2

Installed Versions

INSTALLED VERSIONS

commit : a671b5a
python : 3.11.5.final.0
python-bits : 64
OS : Darwin
OS-release : 21.6.0
Version : Darwin Kernel Version 21.6.0: Mon Aug 22 20:20:05 PDT 2022; root:xnu-8020.140.49~2/RELEASE_ARM64_T8101
machine : arm64
processor : arm
byteorder : little
LC_ALL : None
LANG : None
LOCALE : zh_CN.UTF-8
pandas : 2.1.4
numpy : 1.24.4
pytz : 2023.3.post1
dateutil : 2.8.2
setuptools : 68.1.2
pip : 23.3.1
Cython : 3.0.0a10
pytest : 7.4.3
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : None
IPython : None
pandas_datareader : None
bs4 : None
bottleneck : None
dataframe-api-compat: None
fastparquet : None
fsspec : None
gcsfs : None
matplotlib : 3.4.3
numba : 0.57.0
numexpr : None
odfpy : None
openpyxl : 3.1.2
pandas_gbq : None
pyarrow : None
pyreadstat : None
pyxlsb : None
s3fs : None
scipy : 1.11.4
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
zstandard : None
tzdata : 2023.3
qtpy : None
pyqt5 : None

[rhshadrach]

If you're using .apply(int) as just a simple example, that's perfectly fine, but for that exact operation I think one should prefer .astype(int). But both result in the same issue.

On main, the corresponding example does upcast

df = pd.DataFrame([[1], [2]], columns=['A'])
df.iloc[:, 0] = df.iloc[:, 0].astype(float)
print(df)
#      A
# 0  1.0
# 1  2.0

cc @MarcoGorelli

[MarcoGorelli]

thanks for the report - this looks even odder

In [1]: import pandas as pd
   ...: pd.__version__
   ...: df = pd.DataFrame(
   ...:     [[1.0],[2.5]]
   ...:     , columns=['A']
   ...: )
   ...: df.iloc[:, 0] = df.iloc[:, 0].apply(int)

In [2]: df
Out[2]:
     A
0  1.0
1  2.0

looks like int is applied, but the return dtype is preserved?

EDIT

As commented below, I think this is expected - the right-hand-side is integer dtype, and .iloc preserves the left-hand-side's dtype

[phofl]

@MarcoGorelli I think your example goes back to NumPy behavior

na = np.array([[1.5, 2.5, 3.5], [1.5, 2.5, 3.5]])
na[:, 0] = np.array([1, 2])

NumPy casts here for us, so not warning seems fine

[rhshadrach]

And when the warning being introduced in #56146 goes into effect, pandas will have consistent behavior with respect to upcasting/downcasting.

[MarcoGorelli]

I think this is correct?

So, the R.H.S. evaluates to:

In [3]: df.iloc[:, 0].apply(int)
Out[3]:
0    1
1    2
Name: A, dtype: int64

It's then set into the left-hand-side, preserving the left-hand-side's dtype, so we get

In [5]: df
Out[5]:
     A
0  1.0
1  2.0

@spsspro I think you might want to do it the setitem-way, which isn't in-place:

In [8]: df = pd.DataFrame(
   ...:     [[1.0],[2.0]]
   ...:     , columns=['A']
   ...: )
   ...: df['A'] = df['A'].apply(int)

In [9]: df
Out[9]:
   A
0  1
1  2