SettingWithCopyWarning: A value is trying to be set on a copy of a slice - 10 Causes and Fixes

You ran an assignment on a filtered DataFrame and pandas printed SettingWithCopyWarning: A value is trying to be set on a copy of a slice followed by from a DataFrame. Try using .loc[row_indexer,col_indexer] = value instead. The warning means pandas cannot tell whether the object you just wrote to is a view into the original DataFrame or an independent copy — so it cannot promise your write landed where you think it did.

It is a warning, not an exception. Your script keeps running. That is exactly why it bites: half the time the write silently does nothing, and you find out three transformations later when a column is full of the values you thought you replaced.

This page lists the ten patterns that actually produce it, each with a reproduction you can paste into a REPL and a fix that differs by the specific lines that matter. Then it explains the copy-versus-view design decision underneath, so you can spot the whole family of these on sight.

Error	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 See the caveats in the documentation: https://pandas.pydata.org/pandas-docs/stable/user_guide/indexing.html#returning-a-view-versus-a-copy
Where it happens	Python - pandas (any 0.x/1.x/2.x version prior to Copy-on-Write being enabled by default), raised at assignment time in scripts, notebooks, and ETL jobs
What it means	You assigned into a DataFrame that pandas suspects is a slice of another DataFrame, so the write may hit a temporary copy and be thrown away instead of updating the original.

The Fast Fix

Two rules cover most cases.

If you meant to modify the original DataFrame, do it in one .loc call instead of two indexing steps:

# instead of: df[df['age'] > 30]['bonus'] = 1000
df.loc[df['age'] > 30, 'bonus'] = 1000

If you meant to work on a separate DataFrame, make the copy explicit at the moment you slice:

adults = df[df['age'] > 30].copy()   # .copy() is the whole fix
adults['bonus'] = 1000               # no warning, df untouched

If neither matches your line, work through the diagnostic checklist below — the warning is often raised many lines after the slice that caused it.

What Is Actually Causing It

Jump to your case

• 1. Chained assignment on a boolean-filtered DataFrame
• 2. Assigning to a column of a filtered sub-DataFrame kept in a variable
• 3. Slicing rows with df[start:end] then writing to the slice
• 4. Chained .loc calls - .loc[...] followed by another indexer
• 5. Mutating a group inside a groupby loop
• 6. Writing to a slice inside a function that received a filtered frame
• 7. Reassigning a column on a frame produced by drop, rename, or reset_index
• 8. iterrows and itertuples writes that never reach the DataFrame
• 9. Assigning to a single cell with df['col'][idx] = value
• 10. np.where or fillna applied to a slice instead of the parent

1. Chained assignment on a boolean-filtered DataFrame

Reproduce it

import pandas as pd

df = pd.DataFrame({'name': ['ana', 'bo', 'cy'], 'age': [22, 41, 35], 'bonus': [0, 0, 0]})
df[df['age'] > 30]['bonus'] = 1000
print(df['bonus'].tolist())   # [0, 0, 0] - the write vanished

Why it happens — df[df['age'] > 30] runs __getitem__ first and returns a brand-new object; ['bonus'] = 1000 then calls __setitem__ on that temporary. Boolean masks always produce a copy, so the assignment mutates an object that is discarded on the next line.

The fix

df.loc[df['age'] > 30, 'bonus'] = 1000
print(df['bonus'].tolist())   # [0, 1000, 1000]

What changed: one .loc call with the row mask and column name as a single indexer, so pandas sets values on df itself instead of on a temporary.

Confirm it worked — Print the column on the original DataFrame after the assignment — df['bonus'].tolist() must show the new values, not the old ones.

---

2. Assigning to a column of a filtered sub-DataFrame kept in a variable

Reproduce it

import pandas as pd

df = pd.DataFrame({'city': ['seoul', 'lima', 'oslo'], 'temp': [31, 18, 4]})
hot = df[df['temp'] > 20]
hot['flag'] = 'warm'          # SettingWithCopyWarning

Why it happens — hot carries a _is_copy weak reference back to df. pandas sees you writing to something it knows was derived from another frame and warns, because it cannot prove the write is intentional rather than a lost chained assignment.

The fix

hot = df[df['temp'] > 20].copy()
hot['flag'] = 'warm'          # silent; df has no 'flag' column

What changed: .copy() at the slice site severs the parent link, making the new frame independent by design instead of by accident.

Confirm it worked — Check hot._is_copy is None — with the .copy() it is None, and 'flag' not in df.columns confirms the original was left alone.

---

3. Slicing rows with df[start:end] then writing to the slice

Reproduce it

import pandas as pd

df = pd.DataFrame({'v': [1, 2, 3, 4, 5]})
first_three = df[0:3]
first_three['v'] = 0          # SettingWithCopyWarning

Why it happens — A positional row slice usually returns a view, not a copy — so this write may actually reach df — but pandas cannot guarantee it for every dtype layout, so it warns instead of silently doing something version-dependent.

The fix

# to modify the original:
df.loc[0:2, 'v'] = 0

# to work on a detached frame:
first_three = df.iloc[0:3].copy()
first_three['v'] = 0

What changed: pick one intent explicitly — .loc on the parent, or .copy() on the child. Note .loc[0:2] is label-based and inclusive of 2, unlike iloc[0:3].

Confirm it worked — Run df['v'].tolist() and confirm it matches the intent you chose: [0, 0, 0, 4, 5] for the .loc version, [1, 2, 3, 4, 5] for the copy version.

---

4. Chained .loc calls - .loc[...] followed by another indexer

Reproduce it

import pandas as pd

df = pd.DataFrame({'grp': ['a', 'a', 'b'], 'score': [1, 2, 3]})
df.loc[df['grp'] == 'a'].loc[:, 'score'] = 99   # SettingWithCopyWarning
print(df['score'].tolist())   # [1, 2, 3]

Why it happens — Using .loc does not help if you use it twice. The first .loc[...] returns a new object; the second call sets values on that object. The problem is the chaining, not the indexer you chained with.

The fix

df.loc[df['grp'] == 'a', 'score'] = 99
print(df['score'].tolist())   # [99, 99, 3]

What changed: rows and columns moved into a single bracket as df.loc[rows, cols], so there is exactly one __setitem__ call and it targets df.

Confirm it worked — Count the [ indexer groups on the assignment line — a correct in-place write has exactly one before the =.

---

5. Mutating a group inside a groupby loop

Reproduce it

import pandas as pd

df = pd.DataFrame({'k': ['x', 'x', 'y'], 'v': [1, 2, 3]})
for key, grp in df.groupby('k'):
    grp['v'] = grp['v'] * 2       # SettingWithCopyWarning, df unchanged

Why it happens — Each grp yielded by groupby is a slice of df and carries the copy reference. Writing to it neither reliably updates df nor is collected anywhere — the loop is pure waste.

The fix

df['v'] = df.groupby('k')['v'].transform(lambda s: s * 2)
print(df['v'].tolist())   # [2, 4, 6]

What changed: transform returns a Series aligned to the original index, assigned back to df in one operation, so no per-group mutation is needed.

Confirm it worked — df['v'].tolist() shows the doubled values; the loop version leaves them untouched.

---

6. Writing to a slice inside a function that received a filtered frame

Reproduce it

import pandas as pd

def add_label(frame):
    frame['label'] = 'checked'     # SettingWithCopyWarning here
    return frame

df = pd.DataFrame({'q': [1, 2, 3]})
result = add_label(df[df['q'] > 1])

Why it happens — The function is innocent — the caller passed a slice. The _is_copy link travels with the object across the call boundary, so the warning fires deep inside code that never sliced anything.

The fix

def add_label(frame):
    frame = frame.copy()           # own your input
    frame['label'] = 'checked'
    return frame

result = add_label(df[df['q'] > 1])

What changed: the function copies its input before mutating, so it is safe regardless of what the caller passed. Alternatively fix the call site with df[df['q'] > 1].copy().

Confirm it worked — Call the function with a plain df and with a slice — neither should warn, and 'label' not in df.columns afterwards.

---

More causes (4 remaining)

7. Reassigning a column on a frame produced by drop, rename, or reset_index

Reproduce it

import pandas as pd

df = pd.DataFrame({'a': [1, 2], 'b': [3, 4]})
sub = df[df['a'] > 0]
sub = sub.rename(columns={'b': 'B'})
sub['B'] = 0                       # SettingWithCopyWarning

Why it happens — Methods like rename and reset_index can propagate the _is_copy reference from their input. The frame looks freshly built, but it still remembers it descends from a slice.

The fix

sub = df[df['a'] > 0].copy()
sub = sub.rename(columns={'b': 'B'})
sub['B'] = 0                       # silent

What changed: the copy happens at the original slice, before the chain of transformations, so nothing downstream inherits the parent link.

Confirm it worked — Inspect sub._is_copy right before the failing assignment — if it is not None, the copy is missing further upstream.

---

8. iterrows and itertuples writes that never reach the DataFrame

Reproduce it

import pandas as pd

df = pd.DataFrame({'p': [10, 20]})
for idx, row in df.iterrows():
    row['p'] = row['p'] + 1        # may warn; df never changes

Why it happens — iterrows yields a Series copy of each row, usually with an upcast dtype. Writing to row edits a throwaway object — this is the classic silent-no-op version of the warning.

The fix

df['p'] = df['p'] + 1

# if you truly need per-row logic:
for idx in df.index:
    df.loc[idx, 'p'] = df.loc[idx, 'p'] + 1

What changed: writes target df by index label instead of the yielded row object. Prefer the vectorised first form — the loop is orders of magnitude slower.

Confirm it worked — df['p'].tolist() returns [11, 21]; the iterrows version still returns [10, 20].

---

9. Assigning to a single cell with df['col'][idx] = value

Reproduce it

import pandas as pd

df = pd.DataFrame({'status': ['open', 'open', 'shut']})
df['status'][1] = 'shut'           # SettingWithCopyWarning

Why it happens — df['col'] extracts a Series first, then [1] = ... sets on that Series. Whether the Series shares memory with the frame depends on the block layout, so pandas will not promise the write propagates.

The fix

df.loc[1, 'status'] = 'shut'
# or positionally:
df.iat[1, df.columns.get_loc('status')] = 'shut'

What changed: a single indexer with both axes. .at/.iat are the fastest form for scalar writes.

Confirm it worked — df.loc[1, 'status'] returns 'shut' — read it back off df, never off an intermediate Series.

---

10. np.where or fillna applied to a slice instead of the parent

Reproduce it

import pandas as pd
import numpy as np

df = pd.DataFrame({'region': ['n', 's', 'n'], 'sales': [5, np.nan, 7]})
north = df[df['region'] == 'n']
north['sales'] = north['sales'].fillna(0)      # SettingWithCopyWarning
north['tier'] = np.where(north['sales'] > 6, 'hi', 'lo')   # warns again

Why it happens — fillna and np.where return new values, but the assignment target is still the slice. The right-hand side being pure does not change that the left-hand side writes to a derived frame.

The fix

mask = df['region'] == 'n'
df.loc[mask, 'sales'] = df.loc[mask, 'sales'].fillna(0)
df.loc[mask, 'tier'] = np.where(df.loc[mask, 'sales'] > 6, 'hi', 'lo')

What changed: the mask is computed once and reused as a .loc row indexer on both sides, so results land in df. Non-matching rows get NaN in the new tier column.

Confirm it worked — df.loc[df['region'] == 'n', 'tier'].tolist() returns the computed labels, and df['sales'].isna().sum() reflects the fill.

## None of Those? Narrow It Down

1. Read the traceback line the warning points at, then ask whether the target of = is df itself or a name derived from df. If it is derived, you are in cause 2, 6, or 7; if the line has two [ groups before the =, you are in cause 1, 4, or 9.
2. Count indexing operations on the assignment line. Exactly one indexer before = is safe; two or more is chained assignment regardless of whether you used [], .loc, or .iloc.
3. Print frame._is_copy immediately before the warning line. None means pandas thinks the frame is standalone and the warning came from somewhere else; a non-None weakref means the frame descends from a slice and you need .copy() at that slice.
4. Check whether the write actually took effect: read the value back off the original DataFrame, not off the variable you assigned to. If the original is unchanged, you had a silent no-op, not just a noisy warning.
5. Walk backwards from the warning to the first line that produced the frame — filtering, groupby iteration, iterrows, rename, reset_index, or a function argument. That line is the real site of the bug; the assignment is only where it surfaced.
6. Decide intent out loud: do you want to mutate the original or build a new frame? Mutate → single .loc[rows, cols] = value on the parent. New frame → .copy() at the slice. There is no third answer.
7. If the warning is raised inside library code you do not control, set pd.options.mode.chained_assignment = 'raise' temporarily so it becomes an exception and the traceback shows the exact frame — then revert the setting.
8. If nothing reproduces in isolation, try running with pandas Copy-on-Write enabled (pd.options.mode.copy_on_write = True, available in pandas 2.x). Under CoW, chained assignment never propagates, so any code that depended on a view silently breaking will now fail loudly and consistently.

Why This Error Exists At All

pandas stores a DataFrame's data in NumPy blocks, and NumPy slicing is cheap because it returns views — new array objects pointing at the same memory. That is a feature: slicing a million-row frame costs nothing. But pandas indexing is far richer than NumPy's. A boolean mask, a fancy index, or a slice that crosses mixed dtypes cannot be expressed as a strided view, so pandas must materialise a copy instead. The result: df[something] sometimes shares memory with df and sometimes does not, and which one you get depends on the mask, the dtypes, and the internal block layout — none of which are visible from the calling line.

Now add Python's evaluation order. df[mask]['col'] = 1 is two separate operations: __getitem__ builds an intermediate, then __setitem__ writes to it. Python gives pandas no way to see that these belong to one logical statement, so pandas cannot rewrite it into a single targeted write the way a query planner would. If the intermediate was a view, your write propagates; if it was a copy, it evaporates. Same code, different outcome depending on data.

So pandas does the only honest thing: it tracks a weak reference (_is_copy) from each derived frame to its parent, and when you write to a frame that has one, it warns that the result is undefined by design. The warning is not saying "you did something illegal" — it is saying "I cannot tell you whether this worked." That is why .loc[rows, cols] = value silences it: one indexer means one __setitem__ on a frame pandas can address directly, with no intermediate whose identity is ambiguous. And it is why pandas 2.x introduced Copy-on-Write (pd.options.mode.copy_on_write = True), which makes every indexing result behave as an independent copy — removing the ambiguity entirely at the cost of making chained assignment always a no-op rather than sometimes one. Once you see the pattern — an intermediate object whose view-or-copy status the language cannot reveal — you will recognise it in NumPy slicing, in ORM query results, and anywhere else a cheap-slice API meets an eager-assignment language.

Stop It From Coming Back

• Enable Copy-on-Write early: pd.options.mode.copy_on_write = True at the top of your entry point (pandas 2.x) makes copy-versus-view deterministic and turns the guesswork into a consistent rule.
• Turn the warning into an error in CI with pd.options.mode.chained_assignment = 'raise', or run pytest with -W error::FutureWarning plus a filter for SettingWithCopyWarning, so a silent no-op fails the build instead of shipping.
• Adopt a one-line rule the team can lint by eye: any assignment target must contain at most one indexer. df.loc[rows, cols] = v passes; anything with ][ before the = does not.
• Make .copy() mandatory at the point of slicing when the slice will be mutated — sub = df[mask].copy() — rather than deferring the decision to whoever writes to sub later.
• Replace per-group and per-row mutation loops with groupby(...).transform(...), assign, or vectorised column expressions; these return new objects you assign back explicitly, so the ambiguity never arises.
• Add a pandera schema or a plain post-condition assert after each transformation step (assert df['bonus'].sum() > 0) so a write that quietly failed is caught at the step that made it, not four steps downstream.

Related Guides

• TS2345: Argument of type is not assignable to parameter of type

• TypeError: Cannot read properties of undefined (reading 'map')

• npm ERR! code ERESOLVE unable to resolve dependency tree

• error: Your local changes would be overwritten by merge

Errors You Will Probably Hit Next

• FutureWarning: ChainedAssignmentError: A value is trying to be set on a copy of a DataFrame or Series through chained assignment
• KeyError: 'column_name' - raised when you read a column that a silently-dropped assignment never created
• ValueError: cannot reindex on an axis with duplicate labels - hit when using .loc with a mask on a frame whose index was never reset

When you see this warning, do not reach for a way to suppress it — ask which of two things you meant, because the warning exists precisely because pandas cannot tell. Mutating the original means one .loc[rows, cols] = value on the parent frame. Building a new frame means .copy() at the moment you slice. Then verify by reading the value back off the original DataFrame, since the failure mode here is a write that succeeds at doing nothing.