QST:bug or not? silent fail of df.iloc[].loc[] = newDataType

[matt32106]

If I use a loc chained to a iloc I can change a value if it is of the same dtype:

df = pd.DataFrame([[0, 2, 3], [0, 4, 1], [10, 20, 30]],
...                   index=[4, 5, 6], columns=['A', 'B', 'C'])
df.iloc[1].loc["B"] = 999
df
    A    B   C
4   0    2   3
5   0  999   1
6  10   20  30

This changes the value to 999.
However, this does not work and fails silently if the dtype is different:

df.iloc[1].loc["B"] = "888"
df
    A    B   C
4   0    2   3
5   0  999   1
6  10   20  30

The value is not changed and there is no error raised.
This seems not consistent with the behavior of doing this:

df.iloc[1,1] = "888"
df
    A    B   C
4   0    2   3
5   0  888   1
6  10   20  30

the last code above changes the type of the column silently.

df.dtypes
A     int64
B    object
C     int64

Envirnt:

Python 3.8.5
pd.__version__ : '1.1.3'

I am only a beginner in pandas so I am wondering if this should be reported as a bug or requesting a feature request or if this behavior is normal.

[mzeitlin11]

Please take a look at the Why does assignment fail when using chained indexing? section of https://pandas.pydata.org/docs/user_guide/indexing.html#indexing-view-versus-copy for an in-depth explanation of what's going on here.

Since there are no guarantees about when a view or copy is returned from the step which sets the value, inconsistent behavior like this is expected. In this case, likely the dtype change forces a copy, so the original df is not modified.

However, I would expect

df.iloc[1].loc["B"] = "888"

to give a SettingWithCopy warning, which I am not seeing in master.