Inconsistent SettingWithCopyWarning behavior

[memeplex]

• 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.

---

Code Sample, a copy-pastable example

import numpy as np
import pandas as pd

def example_1():
   df = pd.DataFrame(dict(x=np.arange(100), y=np.arange(100)))
   df_ = df[pd.Series([True] * 50 + [False] * 50, name="y")]
   df_.x *= 2

def example_2():
   df = pd.DataFrame(dict(x=np.arange(100), y=np.arange(100)))
   df_ = df[df.y < 50]
   df_.x *= 2

def example_3():
   df = pd.DataFrame(dict(x=np.arange(100), y=np.arange(100)))
   df_ = df[(df.y < 50) | (np.random.random(100) < 0.5)]
   df_.x *= 2

Problem description

Examples 2 and 3 above show (example 1 doesn't):

/usr/local/lib/python3.8/site-packages/pandas/core/generic.py:5170: SettingWithCopyWarning: 
A value is trying to be set on a copy of a slice from a DataFrame.
Try using .loc[row_indexer,col_indexer] = value instead

I'm failing to see how 2 is different to 1 and how the behavior in 2 is so sticky than even adding a random mask isn't enough to stop it.

I believe that 1 and 2 should behave the same way and, if not, this extremely surprising behavior should at least be clarified in the documentation.

Output of pd.show_versions()

INSTALLED VERSIONS

commit : b5958ee
python : 3.8.6.final.0
python-bits : 64
OS : Darwin
OS-release : 20.1.0
Version : Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:11 PDT 2020; root:xnu-7195.50.7~2/RELEASE_X86_64
machine : x86_64
processor : i386
byteorder : little
LC_ALL : None
LANG : None
LOCALE : None.UTF-8

pandas : 1.1.5
numpy : 1.19.4
pytz : 2020.4
dateutil : 2.8.1
pip : 20.3.1
setuptools : 49.2.1
Cython : 0.29.21
pytest : 6.1.2
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 : 4.9.3
bottleneck : None
fsspec : None
fastparquet : None
gcsfs : None
matplotlib : 3.3.3
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pytables : None
pyxlsb : None
s3fs : None
scipy : 1.5.4
sqlalchemy : 1.3.20
tables : None
tabulate : 0.8.7
xarray : None
xlrd : None
xlwt : None
numba : None

[memeplex]

I'm going to close this for now because I've found out that testing in a fresh kernel all examples show the warning as expected. Then I was able to reproduce it again but I'm not able to provide instructions to deterministically reproduce this yet.

[memeplex]

Ok, here it is, start a fresh kernel copy the above code and run example 1 twice in a row, the first time the warning is shown but not the second time.

The difference between examples 1 and 2 is that for example 2 the warning is shown in both runs.

Another example:

[jreback]

the entire point here is that you are doing something that may work if the memory is a view

it's possible to detect these is most but not all situations

[memeplex]

I get that, Jeff, but I see no difference between using the same boolean mask constructed from scratch or from a condition imposed on a series and I certainly see no difference between the first and the second run.