Description
In 1.3.0 we made it so that df["A"] = foo never operates in-place (xref whatsnew, #33457) and mostly made it so that df.loc[foo, bar] = baz tries to operate in-place before falling back to casting (xref whatsnew, #33457 (comment))
There are some remaining cases where .iloc and .loc do not try to set inplace. This issue is to make sure we have consensus about changing/deprecating that behavior. Most of the impacted test cases involve doing an astype, e.g.
import numpy as np
import pandas as pd
df = pd.DataFrame(np.random.randn(4).reshape(2, 2), dtype=object)
df.iloc[:, 0] = df.iloc[:, 0].astype(np.float64)
ATM this changes df[0] to float64, i.e. is not inplace.
In this case, the user could/should do df[0] = df[0].astype(np.float64). But that approach runs into problems with either non-unique columns or setting a slice of columns df.iloc[:, :2] = foo
My thoughts are that 1) we should be consistent about inplace-ness, not special-case the API and 2) the use case here is convenient.
Thoughts?
update Cataloguing issues/PRs where this behavior we implemented apparently-intentionally
#29393 (#25495)
#6149
#6159 BUG/API: df['col'] = value and df.loc[:,'col'] = value are now completely equivalent
update 2 Cataloguing issues that appear to be caused by/related to this inconsistency
#20635 BUG: indexing with loc and iloc with list-likes and new dtypes do not change from object dtype
#24269 DataFrame.loc/iloc fails to update object with new dtype