DEV Community: Real Dev

The Python Copy Bug That Looks Fine in Code Review

Real Dev — Sat, 17 Oct 2026 05:06:29 +0000

Here is a bug that is easy to ship. A function takes a dict of default settings and hands each new user a copy. Someone adds a tag to one user. Every future user now has that tag too.

The code looks harmless. Each block below runs on its own, and the output under it is what Python 3.13 printed.

defaults = {"theme": "dark", "tags": ["new"]}
user_a = defaults.copy()
user_a["tags"].append("beta")

print("1. shallow copy, then append")
print("   defaults:", defaults)
print("   user_a  :", user_a)
print("   same inner list?", user_a["tags"] is defaults["tags"])

1. shallow copy, then append
   defaults: {'theme': 'dark', 'tags': ['new', 'beta']}
   user_a  : {'theme': 'dark', 'tags': ['new', 'beta']}
   same inner list? True

.copy() made a new dict, so user_a is not defaults. But the new dict holds the same list object under "tags". You copied the outer box and kept pointing at the same contents. That is what "shallow" means. The rest of the interview answer is where it bites.

When you explain it out loud, draw it: two dict boxes, each with an arrow labelled tags going to the same list box. The drawing usually answers the follow-up questions. The is check in the code is the same picture in text. It asks whether two names point at one object, not whether the contents look equal.

The same thing happens with the other usual ways to copy. list(x), x[:] and x.copy() all build a new outer list and share the inner ones:

nested = [["a"], ["b"]]
clones = [list(nested), nested[:], nested.copy()]
print("inner lists shared with the original:", [c[0] is nested[0] for c in clones])

inner lists shared with the original: [True, True, True]

The bug is not specific to .copy(): it appears wherever you wanted an independent copy and wrote the cheap one.

Schoolabe's Python interview questions page lists "What is the difference between shallow copy and deep copy in Python?" in its sample of the question bank. It describes the category as "copying vs references" gotchas that interviewers probe with short follow-ups. Interviewers rarely stop at a definition; they show five lines and ask what prints.

Follow-ups worth rehearsing

The fix everyone knows is copy.deepcopy, which walks the structure and copies everything it finds:

import copy

defaults = {"theme": "dark", "tags": ["new"]}
user_b = copy.deepcopy(defaults)
user_b["tags"].append("beta")

print("2. deepcopy, then append")
print("   defaults:", defaults)
print("   user_b  :", user_b)

2. deepcopy, then append
   defaults: {'theme': 'dark', 'tags': ['new']}
   user_b  : {'theme': 'dark', 'tags': ['new', 'beta']}

Then there is the trap inside the trap: a shallow copy is not always broken. If you replace a value instead of mutating it, the copy is fine.

defaults = {"theme": "dark", "tags": ["new"]}
user_c = defaults.copy()
user_c["theme"] = "light"
user_c["tags"] = user_c["tags"] + ["beta"]

print("3. shallow copy, but rebind instead of mutate")
print("   defaults:", defaults)
print("   user_c  :", user_c)

3. shallow copy, but rebind instead of mutate
   defaults: {'theme': 'dark', 'tags': ['new']}
   user_c  : {'theme': 'light', 'tags': ['new', 'beta']}

The + builds a brand new list and assigns it to the key in the copy only. append changes the list both dicts share. A small difference in how you write the line decides whether the bug exists, and that is the cause behind advice like "just always use deepcopy".

The list-of-lists cousin needs no call to copy at all:

grid = [[0] * 3] * 3
grid[0][0] = 9
print("repeated rows ->", grid)

grid = [[0] * 3 for _ in range(3)]
grid[0][0] = 9
print("comprehension   ->", grid)

repeated rows -> [[9, 0, 0], [9, 0, 0], [9, 0, 0]]
comprehension   -> [[9, 0, 0], [0, 0, 0], [0, 0, 0]]

Multiplying a list repeats the reference, not the row. Three rows, one list. The comprehension fixes it because [0] * 3 is evaluated again for every row, so each row is a fresh list. If someone answers the grid question correctly but can't say why the comprehension works, keep asking; that is the part that matters. I think this is the better thing to ask in a mock interview, because it tells you more about whether someone understands references than the shallow versus deep definition does. You see it in grid and DP problems, where people build a table of zeros.

Is deepcopy just the answer, then?

Not by reflex. It copes with cycles, which surprised me: a list that contains itself deep-copies fine, and the last line of the next block checks it. So correctness isn't the objection. Cost is.

import copy
import time

rows = [list(range(100)) for _ in range(2000)]
times = []
for _ in range(10):
    start = time.perf_counter()
    copy.deepcopy(rows)
    times.append((time.perf_counter() - start) * 1000)
print(f"deepcopy of 2,000 lists of 100 ints: {min(times):.0f} to {max(times):.0f} ms over 10 runs")

loop = [1]
loop.append(loop)
clone = copy.deepcopy(loop)
print("self-referencing list deep-copied fine:", clone[1] is clone and clone is not loop)

deepcopy of 2,000 lists of 100 ints: 26 to 35 ms over 10 runs
self-referencing list deep-copied fine: True

(Your timings will differ.)

That timing is from one machine, so run it yourself. The deepcopy figure held steady across my runs at roughly 25 to 35 ms. I won't quote a ratio against a shallow copy, because a shallow copy of that list is so quick that the timer mostly measures noise.

For a settings object copied once per signup, who cares. Inside a loop that runs a million times, you will care a great deal. The cheaper habit is to not share mutable things in the first place: build new lists with + or a comprehension, or store tags as a tuple so append isn't even possible. Then the shallow copy is safe and you never need the slow one.

My tests only used lists, dicts and ints. Objects with custom __copy__ or __deepcopy__ methods, or ones holding file handles or locks, behave differently, and I didn't try any of them. If an interviewer pushes in that direction, say you would check the class before assuming.

Write down what you think prints before you run it.

Written by the Schoolabe team, who build schoolabe.com. Its homepage says tutorials, quizzes and practice are free, and that lessons and practice problems run in the browser.

Belady's Anomaly: FIFO vs LRU vs Optimal, Checked in Python

Real Dev — Sat, 17 Oct 2026 04:55:09 +0000

Page replacement questions in GATE CS are mostly counting. You get a reference string, a number of frames and a policy, and you write a row of letters. The idea is easy; the marks go when you lose track of the oldest page late in the paper.

So the useful skill is a method you can run without thinking, plus a way to check yourself on practice problems. I wrote a small Python checker for the second part.

Schoolabe's GATE memory management chapter uses this reference string with 3 frames as its worked example:

1 2 3 4 1 2 5 1 2

It says to count FIFO carefully with a queue, and it doesn't print the answer. Here are the three policies, then the numbers. The code blocks in this post are one file, in order; paste them together and it runs.

import random
from collections import OrderedDict, deque

def fifo(refs, frames):
    q, mem, faults, trace = deque(), set(), 0, []
    for p in refs:
        if p in mem:
            trace.append("hit")
        else:
            faults += 1
            if len(mem) == frames:
                mem.remove(q.popleft())
            q.append(p)
            mem.add(p)
            trace.append("F")
    return faults, trace

def lru(refs, frames):
    mem, faults, trace = OrderedDict(), 0, []
    for p in refs:
        if p in mem:
            mem.move_to_end(p)
            trace.append("hit")
        else:
            faults += 1
            if len(mem) == frames:
                mem.popitem(last=False)
            mem[p] = True
            trace.append("F")
    return faults, trace

def opt(refs, frames):
    mem, faults, trace = [], 0, []
    for i, p in enumerate(refs):
        if p in mem:
            trace.append("hit")
            continue
        faults += 1
        trace.append("F")
        if len(mem) < frames:
            mem.append(p)
            continue
        rest = refs[i + 1:]
        # evict the page whose next use is furthest away (or never)
        victim = max(mem, key=lambda x: rest.index(x) if x in rest else float("inf"))
        mem.remove(victim)
        mem.append(p)
    return faults, trace

lesson = [1, 2, 3, 4, 1, 2, 5, 1, 2]
print("Lesson string with 3 frames:", lesson)
for name, policy in (("FIFO", fifo), ("LRU", lru), ("OPT", opt)):
    n, t = policy(lesson, 3)
    print(f"  {name}: {n} faults   {' '.join(t)}")
print("FIFO on the same string with 4 frames:", fifo(lesson, 4)[0], "faults")

Lesson string with 3 frames: [1, 2, 3, 4, 1, 2, 5, 1, 2]
  FIFO: 7 faults   F F F F F F F hit hit
  LRU: 7 faults   F F F F F F F hit hit
  OPT: 5 faults   F F F F hit hit F hit hit
FIFO on the same string with 4 frames: 7 faults

Check the FIFO row by hand. Pages 1, 2, 3 fill the frames. Page 4 evicts 1, so the next 1 faults and evicts 2, so the next 2 faults and evicts 3. Page 5 evicts 4. Then 1 and 2 are both still in memory and hit. Seven faults.

For the hand trace I write the full frame contents under every reference, not just F or hit. For FIFO I underline the oldest page, and for LRU I rewrite the frames in recency order each time. It is slower, but when you go wrong you can see where.

LRU also gets seven here, so LRU does not always beat FIFO on a given string. Optimal gets five, and that is your floor. It needs the future, so no real system can do it. The chapter calls it the offline lower bound, and if your hand trace beats it, you have miscounted.

The anomaly

The chapter says FIFO can show Belady's anomaly, where more frames give more faults, and calls it a favourite trap. The lesson string above doesn't show it: FIFO with 4 frames also gives 7. The textbook string is the same one extended by three pages, 1 2 3 4 1 2 5 1 2 3 4 5.

belady = [1, 2, 3, 4, 1, 2, 5, 1, 2, 3, 4, 5]
print("Classic string:", belady)
for name, policy in (("FIFO", fifo), ("LRU", lru)):
    for frames in (3, 4):
        print(f"  {name}, {frames} frames: {policy(belady, frames)[0]} faults")

Classic string: [1, 2, 3, 4, 1, 2, 5, 1, 2, 3, 4, 5]
  FIFO, 3 frames: 9 faults
  FIFO, 4 frames: 10 faults
  LRU, 3 frames: 10 faults
  LRU, 4 frames: 8 faults

FIFO goes from 9 faults to 10 when it gets a fourth frame. The anomaly was described by Belady, Nelson and Shedler in "An anomaly in space-time characteristics of certain programs running in a paging machine", Communications of the ACM 12(6), June 1969, pp. 349-353 (doi 10.1145/363011.363155).

LRU on the same string drops from 10 to 8, as you would expect. The reason is the stack property: the pages LRU holds with k frames are always a subset of what it holds with k+1 frames. FIFO keeps pages by arrival order, not by use, so it has no such property.

How common is this? I guessed "not very" and wanted a number, so I drew random strings of 12 references over pages 1 to 5, with a fixed seed so you can reproduce it, and compared 3 frames against 4.

random.seed(2026)
trials, bad_fifo, bad_lru = 1_000_000, 0, 0
for _ in range(trials):
    refs = [random.randint(1, 5) for _ in range(12)]
    if fifo(refs, 4)[0] > fifo(refs, 3)[0]:
        bad_fifo += 1
    if lru(refs, 4)[0] > lru(refs, 3)[0]:
        bad_lru += 1
print(f"{trials:,} random strings, 12 refs over pages 1-5, 3 frames vs 4:")
print(f"  FIFO faulted more with 4 frames: {bad_fifo}")
print(f"  LRU faulted more with 4 frames:  {bad_lru}")

1,000,000 random strings, 12 refs over pages 1-5, 3 frames vs 4:
  FIFO faulted more with 4 frames: 1
  LRU faulted more with 4 frames:  0

One hit in a million. A first attempt with 100,000 strings found none, so I'd have written "never" if I'd stopped there. A single hit can't pin down a rate, though, so I also counted exhaustively with a small C program: of all 5^12 = 244,140,625 strings of 12 references over five pages, FIFO faults more with 4 frames than with 3 in exactly 120 of them. That is about 1 in 2 million. It also explains why the textbook string looks hand-built. Someone had to go looking for it.

Don't hunt for the anomaly in the trace. Look at the wording: of these three policies only FIFO can fault more with more frames, so a question asking which one can has its answer before you count anything. If the policy is LRU or Optimal, the anomaly can't be the point.

The checker is also good for something duller. Take any previous-year question with a string and a frame count, run all three policies, and compare with your hand trace. Schoolabe's GATE hub says its previous-year questions show questions and options only for now, and tells you to cross-check the official IIT answer key yourself. That is fair advice for any source, this one included.

CLOCK, the chapter's fourth policy, is not covered here.

Written by the Schoolabe team, who build schoolabe.com. The GATE CS section lists free subject tutorials, topic quizzes and previous-year papers.

SQL Joins Explained with One Tiny Dataset (Plus 5 Interview Questions)

Real Dev — Thu, 15 Oct 2026 16:13:35 +0000

Most join tutorials show you a Venn diagram and move on. Then an interviewer asks, "Why did your row count go up after the join?" or "Why did your LEFT JOIN behave like an INNER JOIN?", and the diagram doesn't help.

In this post we'll use one small dataset (two tables, ten rows in total) and run every join type on it, so you can see exactly which rows survive. Then we'll work through five interview-style questions that test whether you really understand joins, not just the syntax.

Everything below runs on SQLite 3.39 or newer (and on PostgreSQL). If you're on MySQL, everything works except FULL OUTER JOIN, which MySQL doesn't support. We show the usual workaround below.

The setup

Copy this into any SQL editor:

CREATE TABLE departments (
  id   INTEGER PRIMARY KEY,
  name TEXT NOT NULL,
  city TEXT
);

CREATE TABLE employees (
  id         INTEGER PRIMARY KEY,
  name       TEXT NOT NULL,
  dept_id    INTEGER REFERENCES departments(id),
  manager_id INTEGER REFERENCES employees(id),
  salary     INTEGER
);

INSERT INTO departments VALUES
  (1, 'Engineering', 'Bengaluru'),
  (2, 'Sales',       'Mumbai'),
  (3, 'HR',          'Pune'),
  (4, 'Legal',       'Delhi');

INSERT INTO employees VALUES
  (1, 'Asha',  1, NULL, 150000),
  (2, 'Ravi',  1, 1,     90000),
  (3, 'Priya', 2, 1,     80000),
  (4, 'Karan', 2, 3,     60000),
  (5, 'Neha',  NULL, 1,  70000),
  (6, 'Arjun', 3, 1,     65000);

Two details are there on purpose, because they're what make joins interesting:

Neha has no department (dept_id is NULL).
Legal has no employees.

Keep an eye on those two rows. The difference between join types comes down to what happens to them.

INNER JOIN: only matching rows

SELECT e.name, d.name AS dept
FROM employees e
INNER JOIN departments d ON e.dept_id = d.id;

name	dept
Asha	Engineering
Ravi	Engineering
Priya	Sales
Karan	Sales
Arjun	HR

Neha is gone (she matches no department) and so is Legal (it matches no employee). An inner join keeps a row only when the ON condition is true for both sides. JOIN on its own means INNER JOIN.

LEFT JOIN: keep everything from the left table

SELECT e.name, d.name AS dept
FROM employees e
LEFT JOIN departments d ON e.dept_id = d.id;

You get the same five rows plus Neha | NULL. Every employee shows up. Where there's no match, the right-hand columns are filled with NULL. Legal still doesn't appear, because departments is the right table here.

RIGHT JOIN: the mirror image

SELECT e.name, d.name AS dept
FROM employees e
RIGHT JOIN departments d ON e.dept_id = d.id;

Now Legal appears as NULL | Legal, and Neha disappears. In practice most people just swap the table order and write a LEFT JOIN, because it reads more naturally.

FULL OUTER JOIN: keep everything from both

SELECT e.name, d.name AS dept
FROM employees e
FULL OUTER JOIN departments d ON e.dept_id = d.id;

Seven rows: the five matches, Neha | NULL, and NULL | Legal. On MySQL you can get the same result with a LEFT JOIN ... UNION ... RIGHT JOIN of the same two tables.

CROSS JOIN: every combination

SELECT COUNT(*) AS combos
FROM employees CROSS JOIN departments;

That returns 24 (6 employees × 4 departments). You rarely want this on purpose. Usually it shows up by accident when someone forgets the ON condition. If your result ever has "rows × rows" in it, check your join condition first.

Note: SQL doesn't promise any row order unless you write ORDER BY. Your rows may come back in a different order from the tables above. That's fine.

5 interview questions on joins

These are the kinds of questions that separate "I've used joins" from "I understand joins." Try each one yourself before you read the answer.

1. Find departments that have no employees

SELECT d.name
FROM departments d
LEFT JOIN employees e ON e.dept_id = d.id
WHERE e.id IS NULL;

Result: Legal. This is the anti-join pattern: LEFT JOIN, then keep only the rows where the right side didn't match. Check a column that can never be NULL in a real match, such as the primary key e.id. NOT EXISTS is an equally good answer, and it's worth mentioning both.

2. List each employee with their manager's name

SELECT e.name AS employee, m.name AS manager
FROM employees e
LEFT JOIN employees m ON e.manager_id = m.id;

This is a self join: the same table, under two aliases. Interviewers like to ask why it's a LEFT JOIN. The answer: Asha has no manager, and with an INNER JOIN she would disappear from the list.

3. Why did my LEFT JOIN turn into an INNER JOIN?

Compare these two queries:

-- Version A: filter in WHERE
SELECT d.name, e.name
FROM departments d
LEFT JOIN employees e ON e.dept_id = d.id
WHERE e.salary > 70000;

-- Version B: filter in ON
SELECT d.name, e.name
FROM departments d
LEFT JOIN employees e ON e.dept_id = d.id AND e.salary > 70000;

Version A returns 3 rows (Engineering twice, Sales once). Version B returns 5: the same 3, plus HR | NULL and Legal | NULL.

Why? WHERE runs after the join. The unmatched rows have e.salary = NULL, and NULL > 70000 is not true, so WHERE throws them away. Your LEFT JOIN quietly becomes an inner join. If the question is "show every department, and any well-paid employees in it," the filter on the right table belongs in ON.

4. Count employees per department, including empty ones

SELECT d.name, COUNT(*) AS wrong, COUNT(e.id) AS headcount
FROM departments d
LEFT JOIN employees e ON e.dept_id = d.id
GROUP BY d.id, d.name;

name	wrong	headcount
Engineering	2	2
Sales	2	2
HR	1	1
Legal	1	0

COUNT(*) counts rows, and the LEFT JOIN produced one row for Legal (full of NULLs). COUNT(e.id) counts only non-NULL values, which gives the right headcount of 0. Mixing these two up is a classic way to fail this question.

The same idea explains the "why did my row count go up?" question. In a one-to-many join, each department row is repeated once for every matching employee. That's correct behaviour. Just remember it before you SUM a column from the "one" side.

5. Highest-paid employee in each department

Version with a correlated subquery:

SELECT d.name AS dept, e.name, e.salary
FROM employees e
JOIN departments d ON e.dept_id = d.id
WHERE e.salary = (
  SELECT MAX(e2.salary)
  FROM employees e2
  WHERE e2.dept_id = e.dept_id
);

Version with a window function:

SELECT dept, name, salary
FROM (
  SELECT d.name AS dept, e.name, e.salary,
         RANK() OVER (PARTITION BY e.dept_id ORDER BY e.salary DESC) AS rnk
  FROM employees e
  JOIN departments d ON e.dept_id = d.id
)
WHERE rnk = 1;

Both return Asha (Engineering), Priya (Sales) and Arjun (HR). A good follow-up to bring up yourself is ties: RANK() keeps every employee tied for the top salary, while ROW_NUMBER() would pick exactly one of them.

A quick mental checklist

Before you run any join, ask yourself:

Which rows must not disappear? That table goes on the left of a LEFT JOIN.
Is this one-to-one or one-to-many? If it's one-to-many, expect repeated rows and be careful with aggregates.
Where does each filter go? Filters on the optional (right) table usually belong in ON.
What am I counting? COUNT(*) counts rows. COUNT(col) counts non-NULL values.

Try it in the browser

Reading about joins only gets you so far. You need to write a few that go wrong. Our hands-on SQL practice has chapters on INNER JOIN, outer joins and NULL handling, with exercises you run in the browser. Nothing to install.

A good exercise: extend the dataset above with a projects table (id, name, dept_id) and write a query that lists every department with its number of employees and its number of projects. If you get inflated counts, go back to question 4.

Happy querying!

— Schoolabe team