Skip to content

DEPR: enforce inplaceness for df.loc[:, foo]=bar #49775

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 14 commits into from
Dec 21, 2022

Conversation

jbrockmendel
Copy link
Member

@jbrockmendel jbrockmendel commented Nov 18, 2022

  • closes #xxxx (Replace xxxx with the GitHub issue number)
  • Tests added and passed if fixing a bug or adding a new feature
  • All code checks passed.
  • Added type annotations to new arguments/methods/functions.
  • Added an entry in the latest doc/source/whatsnew/vX.X.X.rst file if fixing a bug or adding a new feature.

cc @jorisvandenbossche i expect the CoW-case edits in the copy_view tests are unwanted. pls advise.

@mroeschke mroeschke added the Deprecate Functionality to remove in pandas label Nov 18, 2022
@@ -340,7 +340,7 @@ def test_subset_set_column_with_loc(using_copy_on_write, using_array_manager, dt
# The (i)loc[:, col] inplace deprecation gets triggered here, ignore those
# warnings and only assert the SettingWithCopyWarning
with tm.assert_produces_warning(
SettingWithCopyWarning,
None,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be considered as a false negative? (I would expect a warning here, but in general we are not super consistent about when we warn and when not)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i dont fully grok when we should be issuing the warning, but I think that no copies are being made here, so it would make sense to not get the warning

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in the past, we have often raised warnings both when the actual object is a copy (and people might think it is a view) or a view (and people might think it is a copy), despite the exact name of the warning. Now, I don't know if we ever clearly defined in which cases the warning should be raised, though ;)

It also seems to depend on the dtypes and the exact value that is being set, as I was running the above example on released pandas and eg when changing the setitem from df.loc[:, 'a'] to df.loc[1, 'a'] (scalar), the it does raise a warning with a single block, but not for a df with multiple dtypes ...

@jbrockmendel jbrockmendel added the Indexing Related to indexing on series/frames, not to indexes themselves label Nov 19, 2022
Copy link
Member

@mroeschke mroeschke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One small comment otherwise looks okay to me

@mroeschke mroeschke added this to the 2.0 milestone Dec 5, 2022
Copy link
Member

@jorisvandenbossche jorisvandenbossche left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Added a question about the implementation (whether the internals already can do this as well), and a bunch of small nits on the tests.

If I do a search for "will attempt" in the codebase, there are a few remaining ones that can be cleaned-up:

  • pandas/tests/frame/test_nonunique_indexes.py in test_set_value_by_index
  • pandas/tests/frame/methods/test_sort_index.py a mark.filterwarnings

df.loc[:, "Alpha"] = categories
# pre-2.0 this swapped in a new array, in 2.0 it operates inplace,
# consistent with non-split-path
df.loc[:, "Alpha"] = categories
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think it would be worth to also test a non-inplace way (I suppose normal setitem?) to still somewhat cover the original bug?
(although I can imagine that those code paths are completely different, and different from the time of the bug, and maybe already tested elsewhere, so not necessarily worth it)

@mroeschke
Copy link
Member

Everything here looks mostly address so going to merge. Can create follow up PRs if there are any followups needed

@mroeschke mroeschke merged commit 4e4be0b into pandas-dev:main Dec 21, 2022
@jbrockmendel jbrockmendel deleted the depr-inplace-setting branch December 21, 2022 20:16
xyxel added a commit to xyxel/pandas that referenced this pull request May 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Deprecate Functionality to remove in pandas Indexing Related to indexing on series/frames, not to indexes themselves
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants