Skip to content

BUG: SettingWithCopyError raised unsystematically (?) #39418

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

Closed
2 of 3 tasks
nolanbconaway opened this issue Jan 26, 2021 · 2 comments · Fixed by #56614
Closed
2 of 3 tasks

BUG: SettingWithCopyError raised unsystematically (?) #39418

nolanbconaway opened this issue Jan 26, 2021 · 2 comments · Fixed by #56614
Labels
Bug Copy / view semantics Warnings Warnings that appear or should be added to pandas

Comments

@nolanbconaway
Copy link

  • 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

pd.options.mode.chained_assignment = "raise"


def f(df):
    res = df["a"]
    is_two = df["a"] == 2
    res.loc[is_two] = None
    return res


df1 = pd.DataFrame(dict(a=range(3)))
df2 = df1.assign(b=pd.date_range("2020-01-01", "2020-01-03"))

f(df1)  # no problem
f(df2)  # SettingWithCopyError

Problem description

The function above selects a column a, finds the position of values that are equal to two and sets those values to None, then returns the a Series.

When a dataframe only contains the a column, there is no problem. When a datetime column is introduced, SettingWithCopyError is raised.

Expected Output

Because the function f does not access any column besides a, I expect it to behave identically for both dataframes.

Output of pd.show_versions()

INSTALLED VERSIONS

commit : 9d598a5
python : 3.8.5.final.0
python-bits : 64
OS : Darwin
OS-release : 19.6.0
Version : Darwin Kernel Version 19.6.0: Tue Nov 10 00:10:30 PST 2020; root:xnu-6153.141.10~1/RELEASE_X86_64
machine : x86_64
processor : i386
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 1.2.1
numpy : 1.19.4
pytz : 2020.4
dateutil : 2.8.1
pip : 20.3.3
setuptools : 47.1.0
Cython : None
pytest : None
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : 2.8.6 (dt dec pq3 ext lo64)
jinja2 : 2.11.2
IPython : 7.19.0
pandas_datareader: None
bs4 : None
bottleneck : None
fsspec : None
fastparquet : None
gcsfs : None
matplotlib : 3.3.3
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyxlsb : None
s3fs : None
scipy : 1.5.4
sqlalchemy : None
tables : None
tabulate : None
xarray : 0.16.2
xlrd : None
xlwt : None
numba : None

@nolanbconaway nolanbconaway added Bug Needs Triage Issue that has not been reviewed by a pandas team member labels Jan 26, 2021
@nmay231
Copy link
Contributor

nmay231 commented Feb 10, 2021

The issue here is you are implicitly using chained-assignment. The function you wrote boils down to:

def f(df):
    df['a'].loc[df['a'] == 2] = None
    return df['a'].loc[df['a'] == 2]

That is because res = df["a"] creates a reference to the "a" column, not a copy that you are allowed to modify. There is an easy fix.

def f(df):
    res = df['a'].copy() # copy the column
    is_two = df['a'] == 2
    res.loc[is_two] = None
    return res

To be honest, I'm not certain why it only raises an error/warning with the second dataframe. Maybe it has to do with a subtle threshold where fully numeric dataframes automatically copy columns on access? E.g. maybe df['a'] is the same as df['a'].copy() for numeric dataframes? That would be my assumption.

In any case, you can look at this post for a more detailed explanation about chain-expressions.

@nolanbconaway
Copy link
Author

Hi @nmay231 ! Thanks for looking at this. I'm aware of the causes of the SettingWithCopyWarning/Error, its fixes, etc, but the bug that I am specifically referring to in this issue is that it is raised inconsistently!

My thinking is that if one is setting with a reference, that the error should be raised regardless of what other data is in the frame. Is this not the desired behavior?

@mroeschke mroeschke added Copy / view semantics Warnings Warnings that appear or should be added to pandas and removed Needs Triage Issue that has not been reviewed by a pandas team member labels Aug 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Copy / view semantics Warnings Warnings that appear or should be added to pandas
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants