Why an assignment that looks right silently does nothing - and the one habit that prevents it.
Overview
The problem
Chained indexing is the source of one of the most confusing errors in pandas. The code looks correct. It selects rows, then assigns a value. Sometimes it works. Sometimes it silently does nothing. The outcome depends on whether an intermediate object shares memory with the original frame or is an independent copy.
That unpredictability is the real issue. If it always failed, you would learn the pattern and avoid it. If it always worked, there would be no problem. Because it depends on internal memory layout, the same code can behave differently depending on the dtypes, the size of the frame, or the version of pandas.
The SettingWithCopyWarning was added to catch this. It appears when pandas detects that an assignment might have landed on a temporary object. The warning is accurate in intent but confusing in practice. It fires on code that is fine and sometimes misses code that is not.
The fix is straightforward. Use a single loc or iloc expression for combined selection and assignment. That avoids the intermediate object entirely. The assignment goes directly into the original frame, with no ambiguity about where the write lands.
This module explains why the problem exists, what the warning means, and how to write assignments that are unambiguous. It also covers the copy-on-write mode introduced in newer pandas versions, which changes the default behaviour so that every indexing operation returns an independent copy. That eliminates the ambiguity at the cost of requiring an explicit copy when you want shared memory.
df[df["age"] < 30]["age"] = 99
This looks like it sets age to 99 for the young rows. Often it does nothing at all, and the frame is unchanged.
there are two steps here, not one.
df[df["age"] < 30] runs first and makes a new object. Then ["age"] = 99 assigns into *that* object. Whether the new object shares memory with df decides whether df sees the change. And if it doesn't, the write lands on a temporary that is discarded on the next line.
Once pandas noticed this pattern and raised SettingWithCopyWarning. The warning is famous for being confusing. It appears where the code looks fine, it at times appears when nothing is wrong. It at times fails to appear when a thing is. In current versions the set may simply do nothing, silently.
Worth knowing
Chained assignment — two sets of brackets left of = — may write to a temporary and silently leave your frame unchanged.
Put the row and column selection in one.loc[] call and the write always lands on the frame.
Whether a selection is a view or a copy depends on the internal block layout — and the mixed-dtype frame is the one that gives a view, which is the reverse of what most people guess.
Editing a filtered subset is the usual way this bites — the writes may or may not reach the original.
Say which you meant: .copy() for a separate frame, .loc[...] = ... to change the original.
Copy-on-write makes a selection never write back. It is the default in pandas 3.0 and can be switched on today.
The Copy Warning
Why an set that looks right silently does nothing.
The assignment that does nothing
Two sets of brackets, and the write may land on a temporary instead of your frame.
example_01.pypandas
import pandas as pd
df = pd.DataFrame({"name": ["ana", "raj", "kim"], "age": [31, 25, 40]})
print("before:", list(df["age"]))
df[df["age"] < 30]["age"] = 99 # chained: two operations
print("after :", list(df["age"]))
print()
print("The frame is unchanged. The write went to the object the first")
print("bracket returned, which was thrown away on the next line.")
print()
print("A SettingWithCopyWarning is printed above this output, in red -")
print("that is pandas telling you the write probably did nothing.")
Output
The same thing in one loc call
One indexing operation on df itself, so pandas knows where to write.
example_02.pypandas
import pandas as pd
df = pd.DataFrame({"name": ["ana", "raj", "kim"], "age": [31, 25, 40]})
print("before:", list(df["age"]))
df.loc[df["age"] < 30, "age"] = 99
print("after :", list(df["age"]), "<- it worked")
print()
print("The rule: row selection and column selection go in ONE .loc[].")
print("Anything with two sets of brackets on the left of = is suspect.")
Output
Why pandas cannot always tell
Whether a selection is a view or a copy depends on the dtypes involved.
example_03.pypandas
import pandas as pd
same = pd.DataFrame({"a": [1, 2, 3], "b": [4, 5, 6]})
mixed = pd.DataFrame({"a": [1, 2, 3], "b": ["x", "y", "z"]})
for name, frame in [("all int", same), ("int + str", mixed)]:
sub = frame[["a"]]
sub_is_view = sub._is_view if hasattr(sub, "_is_view") else None
print("%-10s selecting ['a'] -> _is_view = %s" % (name, sub_is_view))
print()
print("Identical code, opposite answers - and note it is the MIXED")
print("frame that gave the view here, which is the reverse of what")
print("most people guess.")
print()
print("The reason is internal: pandas stores columns in blocks of like")
print("dtype. In the mixed frame 'a' is a block of its own and can be")
print("handed back directly; in the all-int frame it is part of a")
print("larger block, so selecting it has to build something new.")
print()
print("None of that is visible in your code, and it changes when a")
print("column's dtype changes. That is why pandas refuses to guess.")
Output
It bites hardest on a filtered frame
Take a subset, work on it, and the writes may or may not reach the original.
example_04.pypandas
import pandas as pd
df = pd.DataFrame({
"city": ["pune", "delhi", "pune"],
"sales": [10, 20, 30],
})
sub = df[df["city"] == "pune"] # a new frame, probably a copy
sub["sales"] = 0 # writing into it
print("the subset:"); print(sub)
print()
print("the original:"); print(df)
print()
print("Whether df changed is the question you never want to be asking.")
print("If you meant a separate frame, say so with .copy().")
Output
Be explicit: copy() or loc
Decide which one you want, and the ambiguity disappears.
example_05.pypandas
import pandas as pd
df = pd.DataFrame({"city": ["pune", "delhi", "pune"], "sales": [10, 20, 30]})
# 1. I want a separate frame to work on
sub = df[df["city"] == "pune"].copy()
sub["sales"] = 0
print("after editing an explicit copy, original is untouched:")
print(list(df["sales"]))
# 2. I want to change the original
df.loc[df["city"] == "pune", "sales"] = 0
print()
print("after a single loc assignment, original changed:")
print(list(df["sales"]))
print()
print("Every case is one of those two. Writing which one you meant")
print("costs seven characters and removes the whole problem.")
Output
Copy-on-write, the way out
pandas 3.0 makes every selection behave like a copy. You can switch it on now.
example_06.pypandas
import pandas as pd
print("pandas", pd.__version__)
pd.options.mode.copy_on_write = True
df = pd.DataFrame({"a": [1, 2, 3]})
sub = df[df["a"] > 1]
sub["a"] = 0
print()
print("with copy_on_write ON:")
print(" subset :", list(sub["a"]))
print(" original:", list(df["a"]), "<- never affected, no warning")
pd.options.mode.copy_on_write = False
print()
print("Under copy-on-write the rule is simple: a selection NEVER writes")
print("back. To change the original you must say df.loc[...] = ...")
print("It is the default from pandas 3.0 - writing code that way now")
print("means nothing changes when you upgrade.")
Output
Why pandas cannot just fix it
The obvious question is why pandas doesn't make chained set work.
It can't know, at the time the first bracket runs, that an set is coming. df[mask] is an plain formula that returns an object. Python then calls __setitem__ on that object. By then the data that this was one statement is gone.
Whether the mid is a view or a copy depends on the inner layout. This Depends on the dtypes.
pandas stores columns in blocks of like dtype. Selecting a column that happens to be a block of its own can hand back a view. Selecting one column out of a larger same-dtype block has to build a new object.
The editor above shows this, and the direction surprises most people. The mixed-dtype frame gives the view. There the int column sits in a block by itself. The all-int frame gives a copy, because its columns share one block.
So the same line of code can work on one frame and not another, or work in development and fail in production when a column's type changes. That unpredictability, not the warning, is the actual problem.
The rule
One indexing step, with both picks inside it.
df.loc[df["age"] < 30, "age"] = 99
Here pandas sees a single __setitem__ on df itself, with the rows and column both given. There's no mid object and no ambiguity.
Anything with two sets of brackets to the left of = deserves a second look. That includes the variants people reach for:
df["age"][mask] = 99 — same problem, other order.
df[mask]["age"] = 99 — the classic.
sub = df[mask] then later sub["age"] = 99. The same thing spread across two statements. This Is how it often appears in real code and why it's harder to spot.
The subset case
The most common real-world version isn't a one-liner. It's:
sub = df[df["city"] == "pune"]
sub["sales"] = 0
Here the intent is truly ambiguous. Did you want a split frame to work on, or did you want to change those rows of df?
Both are fair, and the fix is to say which:
sub = df[df["city"] == "pune"].copy() # a separate frame
df.loc[df["city"] == "pune", "sales"] = 0 # change the original
.copy() costs seven characters and drops the entire question. It's worth adding by default when you take a subset you intend to modify, even if you're fairly sure it would work without.
Copy-on-write
pandas is fixing this properly. Under copy-on-write, each pick behaves as though it were a copy. Modifying a subset never affects the parent, in any circumstances, with no warning and no dtype-dependent surprises.
To change the first you must say so with .loc.
It's the default in pandas 3.0. In 2.x you can switch it on:
pd.options.mode.copy_on_write = True
The name refers to the setup, not the action. Pandas still avoids copying data until a thing is really written. It isn't slower and is often faster. It can drop the defensive copies it used to make.
Writing code that assumes copy-on-write today means nothing changes when you upgrade. that means the two habits above. Clear .copy(). .loc for set. Which are worth having even so.
If you see the warning
Don't silence it. pd.options.mode.chained_assignment = None turns off the message and leaves the bug.
Instead, find the line, and ask which of the two things you meant. The answer is always one of them, and writing it down fixes the code and docs the intent also.
How to read the warning
The message is famously unhelpful. But It has a structure worth knowing.
*"A value is trying to be set on a copy of a slice from a DataFrame"*. Pandas noticed that the object being written to was made by indexing another object. It can't tell whether the write will pass.
*"Try using .loc[row_indexer, col_indexer] = value instead"*. The fix, stated generically.
Two properties make it frustrating.
It points at the set. This May be far from the line that created the mid. sub = df[mask] on line 10 and sub["x"] = 1 on line 40 give a warning on line 40. Line 10 is the cause.
It's a heuristic. It can fire when nothing is wrong. It can stay silent when a thing is. That is why "make the warning go away" is the wrong goal. The goal is to know which object you're writing to.
Why silencing it is worse than the warning
pd.options.mode.chained_assignment = None turns off the message.
It doesn't change the action. The write still may or may not reach the first frame. You've simply removed the only signal that there was a question.
You'll see this suggested. It's the wrong fix in each case. It's worth recognising in an existing code as a sign that someone met this problem and didn't resolve it.
The two-statement version
Most real cases aren't one-liners. They look like this:
This is harder to spot than the chained form. Each line looks fully fair. It's the shape that appears in real analysis code.
The question to ask is: **is recent a split dataset, or a window onto df?**
If split: recent = df[df["year"] == 2024].copy().
If a window: don't create it. Write df.loc[df["year"] == 2024, "flag"] = ....
Adding .copy() when taking a subset you intend to modify is a cheap default. On a small frame the cost is nothing. On a large one it's a deliberate choice you've now made by name rather than by accident.
Copy-on-write in more detail
Under CoW, each object behaves as though it owns its data. Modifying a subset never affects its parent. Modifying a parent never affects a subset taken earlier.
The name shows the setup: pandas still shares the underlying arrays. Only copies when a thing is really written. So the promise is about action, not about memory. CoW often uses *less* memory than the current default. Pandas can drop the defensive copies it makes today.
Three things change when you enable it:
Chained set never works, and pandas raises a ChainedAssignmentError rather than warning.
SettingWithCopyWarning disappears, because the ambiguity it warned about is gone.
Some code that leaned on a view passing a write will stop working. Which is the migration cost. The reason it's opt-in until pandas 3.0.
Turning it on in a project today is a good way to find out whether your code depends on action that is about to change.
A checklist
**Two sets of brackets left of =**. Rewrite as one .loc.
A subset you'll modify — add .copy().
A warning you don't understand. Find where the object was created, not where it was written.
**A tempting chained_assignment = None** — don't.
New code — write it as though copy-on-write is on. Soon it will be.
Why this module exists
No other pandas action wastes as much time. The warning is famous, the reasons are often wrong. The standard advice on forums. Silence it. Leaves the bug in place.
The underlying issue is truly hard: Python tests df[mask]["col"] = x as two split steps. By the time the set happens the data that this was one statement is gone. pandas is warning about a thing it can't fix from where it stands.
Understanding that makes the fix obvious rather than any. One indexing step can't be ambiguous. Put both picks in one call.
The rules, in one place
**One .loc for set.** df.loc[mask, "col"] = value.
**.copy() for a subset you'll modify.** sub = df[mask].copy().
Never silence the warning. It drops the signal, not the problem.
Write as though copy-on-write is on. It will be, by default, in pandas 3.0.
Those four cover each case. There's no fifth situation needing judgement.
Recognising it in existing code
Patterns worth searching for in a code you've from parent:
][ on the same line as =. The classic chained set.
pd.options.mode.chained_assignment = None — someone met this and didn't fix it. all downstream of that line is suspect.
inplace=True on a subset — the same problem with other syntax.
A var assigned from a filter and modified later. The two-statement form. This No search finds well and which is the most common version in real code.
What changes under copy-on-write
Worth being concrete, because "it will be fixed" isn't a plan.
Chained set raises ChainedAssignmentError instead of warning. So The failure is loud.
SettingWithCopyWarning no longer exists.
Code that leaned on a view passing a write. on purpose or accidentally. Stops working. That is the migration cost. It's why the change is opt-in for a version.
Memory usage often goes down, because pandas can stop making defensive copies.
Enabling pd.options.mode.copy_on_write = True in a project today is the cheapest way to find out whether any of your code depends on the old action.
The one-line version
If you note nothing else from this module: two sets of brackets to the left of an equals sign is a bug. .loc with both picks inside it's the fix.
A closing note on the Copy Warning
This is the only module in the track devoted to a warning message. It earns the space by how much time it wastes.
The underlying situation is truly awkward. df[mask]["col"] = x is two steps. By the time the set runs, that it was one statement is gone. pandas can't fix it from where it stands. It warns instead. Imperfectly, at times when nothing is wrong and at times not when a thing is.
That imperfection is why "make the warning stop" is the wrong goal. The right goal is to know which object you're writing to. There are only two answers. A split frame you made with .copy(), or the first, handled through a single .loc.
Copy-on-write drops the ambiguity fully and turns the default in pandas 3.0. Writing code today as though it's already on costs nothing and means the upgrade changes nothing.
Questions people ask about the Copy Warning
What does SettingWithCopyWarning actually mean? pandas cannot tell whether you are writing to a copy or to a view of the original frame. Your assignment may not reach the frame you meant to change.
How do I make the warning go away properly? Call .copy() when you intend an independent subset, or use a single df.loc[mask, 'col'] = value when you intend to modify the original.
Why not just turn the warning off? Silencing it hides real bugs where your assignment is lost. The warning is a symptom of code whose result depends on internal details.
What is copy-on-write? It is a pandas mode in which any derived object behaves as a copy, so changing it never changes its parent. It removes the ambiguity and the warning, and it is the default from pandas 3.0.
Is chained indexing always a problem? Chained assignment such as df[mask]['a'] = 1 is the problem. Chained reading such as df[mask]['a'] is fine, though a single loc is clearer.
How do I check whether I have a copy or a view? You cannot rely on a check, because it depends on dtypes and the operation. Write code that makes the intent explicit with .copy() or one loc call.
One more thing
df._is_copy holds the inner flag that drives the warning. It's private, it shouldn't be leaned on. Knowing it exists at times helps when thinking about why a warning appeared where it did.
Check yourself
0 of 4
Answer without scrolling back up.
Why can `df[mask]['col'] = x` fail to change `df`?
By the time Python calls __setitem__ on the intermediate, the information that this was one statement is gone.
Why can't pandas simply make chained assignment work?
Columns are stored in blocks of like dtype, and which case you get is invisible in your code - it changes when a column's dtype changes.
You take `sub = df[df['city']=='pune']` and intend to edit it separately. What should you add?
It costs seven characters and removes the ambiguity entirely. Use df.loc[...] = ... instead if you meant to change the original.
What does copy-on-write change?
It is the default in pandas 3.0. The name describes the implementation - data is still not copied until something is written.
Cheat sheet
The Copy Warning
Understand why chained indexing makes assignments silently fail, and how to write the line that actually changes the DataFrame.
Ashish Jangra builds and maintains VizLearn. Every module here is written and the visualisation behind it hand-built, so the numbers in a readout come from the same code that draws the picture. Corrections are genuinely welcome and get priority over everything else — if a page states something wrong, or an animation misrepresents what the algorithm does, get in touch.