DEV Community: Muiduzzaman Lipu

One Change Made My Python Code 2,000 Faster (Lists vs Sets)

Muiduzzaman Lipu — Tue, 10 Nov 2026 12:40:14 +0000

One tiny change made this Python code over 2,000× faster. Same logic, same result. The only difference is a list versus a set.

Here's the video version (2 minutes):

The slow code

A common task: 20,000 users, a list of 20,000 banned emails, find which users are banned.

users  = [...]   # 20,000 emails
banned = [...]   # 20,000 banned emails (a list)

flagged = [u for u in users if u in banned]

One line, looks perfectly fine. On my machine it took 1.31 seconds.

The fix: one function call

banned = set([...])   # a set instead of a list

flagged = [u for u in users if u in banned]

The comprehension doesn't change at all, and it returns the same 10,000 results. It now takes 0.61 milliseconds. That's over 2,000× faster, and building the set took less than a millisecond.

Why: how `in` works

x in list checks the items one by one until it finds a match → O(n)
x in set hashes x and jumps straight to the slot where it would be stored → O(1) on average
Dictionary keys work the same way: key in my_dict is O(1)

With lists, our example is up to 20,000 × 20,000 = 400 million comparisons. With a set, it's 20,000 hash lookups.

Measured: a single lookup at different sizes

Worst case (the item is at the end of the list):

n =     1,000   list     4.3 µs   set  0.021 µs
n =   100,000   list   455.0 µs   set  0.027 µs
n = 1,000,000   list  4560.7 µs   set  0.027 µs

The list gets ~100× slower when the data gets 100× bigger. The set barely moves. At a million items, a set lookup was over 170,000× faster.

When to use a set (and when not to)

✅ Use a set when:

You check membership (in) many times against the same collection
You want to remove duplicates: set(items)
You need intersections or differences: a & b, a - b

❌ Keep a list when:

You need order, indexes, or duplicates
You only look something up once: converting to a set costs more than it saves

Try it on your code

Search your codebase for in followed by a big list inside a loop. You might find a free speedup.

I post one tested coding tip every day on YouTube at Refactorly. The 30-second version of this one is here.

The Python Bug That Fools Everyone: Mutable Default Arguments

Muiduzzaman Lipu — Tue, 10 Nov 2026 12:40:10 +0000

This tiny function looks completely fine. It has a bug that has fooled beginners and senior developers alike:

def add_item(item, items=[]):
    items.append(item)
    return items

print(add_item("apple"))   # ['apple']
print(add_item("banana"))  # ['apple', 'banana']  😱

The second call returns ['apple', 'banana']. Where did apple come from? We never passed a list in.

Here's the 2-minute video version if you prefer watching:

Why it happens: defaults are created once

Default values are evaluated once, when the function is defined, not every time it's called. Every call that doesn't pass items shares the same list object.

You can actually see it, hiding inside the function:

>>> add_item("apple")
['apple']
>>> add_item("banana")
['apple', 'banana']
>>> add_item.__defaults__
(['apple', 'banana'],)

The default list lives on the function object and grows with every call.

The fix: use `None` and create the list inside

def add_item(item, items=None):
    if items is None:
        items = []
    items.append(item)
    return items

Now every call that doesn't pass a list gets its own brand-new one. This is the standard Python pattern, and you'll see it all over the standard library.

Same trap, different shape: frozen timestamps

It's not just lists. Anything in a default is evaluated once:

from datetime import datetime

def log(msg, when=datetime.now()):  # evaluated once!
    print(when, msg)

log("first")
log("second")  # same time as "first" 🤔

datetime.now() runs only when the function is defined, so every log line gets the same frozen timestamp, even hours later. Same fix: default to None, and compute the time inside the function.

Dataclasses protect you (use `default_factory`)

Dataclasses refuse mutable defaults outright:

@dataclass
class Cart:
    items: list = []

# ValueError: mutable default <class 'list'> for field items is not allowed: use default_factory

The correct way:

from dataclasses import dataclass, field

@dataclass
class Cart:
    items: list = field(default_factory=list)

default_factory builds a new list for every instance.

Bonus pitfall: `items = items or []`

You'll often see this shortcut:

def fill(items=None):
    items = items or []   # [] is falsy!
    items.append(1)

mine = []
fill(mine)
print(mine)  # [] (your list was ignored!)

An empty list is falsy, so if the caller passes their own empty list, it gets silently replaced with a new one. Always check is None explicitly:

def fill(items=None):
    if items is None:
        items = []
    items.append(1)

mine = []
fill(mine)
print(mine)  # [1] ✅

Recap

Default values are evaluated once, at definition time
Never use [], {} or set() as defaults
Use None and create the object inside the function
In dataclasses: field(default_factory=list)
Check is None, not or

Have you been bitten by this one? Tell me in the comments.

I post one tested coding tip every day on YouTube at Refactorly. The 30-second version of this one is here.

4 useEffect Mistakes Almost Every React Dev Makes (I Ran Them All in React 19)

Muiduzzaman Lipu — Tue, 10 Nov 2026 12:40:05 +0000

useEffect is the most misused hook in React. Most of the time the bug isn't obvious: the component looks fine, until your API gets hammered or the wrong user's data shows up on screen.

I took four common mistakes, ran each one in real React 19 (rendered with react-dom in a simulated browser), and counted what actually happens. Here are the results and the fix for each.

Prefer video? Here's the 3-minute version:

Mistake 1: an object in the dependency array → infinite loop

function UserList() {
  const [users, setUsers] = useState([]);
  const filters = { active: true }; // new object every render!

  useEffect(() => {
    fetchUsers(filters).then(setUsers);
  }, [filters]);

  return <p>{users.length} users</p>;
}

React compares dependencies by reference. Every render creates a brand-new filters object, so React thinks it changed. The effect runs, calls setUsers, which re-renders, which creates a new object, which runs the effect again. Forever.

I counted the calls with a mocked fetchUsers:

fetchUsers called 15002 times in 1 second   ❌
fetchUsers called 1 times in 1 second       ✅ (fixed)

With a real API, that's your server getting hammered.

Fix: keep fresh objects and arrays out of the dependency array.

useEffect(() => {
  fetchUsers({ active: true }).then(setUsers);
}, []);

Other options: depend on primitive values ([active] instead of [filters]), or wrap the object in useMemo.

Mistake 2: no cleanup → leaks (and a double timer)

useEffect(() => {
  setInterval(() => {
    setSeconds(s => s + 1);
  }, 1000);
}, []);

Nothing stops this interval. When the component unmounts, it keeps running. Here's what I measured inside <StrictMode>:

# without cleanup
after 5 seconds:     10s       ❌ (two timers!)
3 s after unmount:   6 ticks still running ❌

# with cleanup
after 5 seconds:     5s        ✅
3 s after unmount:   0 ticks   ✅

Why did it count double? In development, Strict Mode intentionally mounts, unmounts and re-mounts your effects to expose missing cleanup. Without cleanup you end up with two intervals.

Fix: return a cleanup function. React calls it before the effect re-runs and when the component unmounts.

useEffect(() => {
  const id = setInterval(() => {
    setSeconds(s => s + 1);
  }, 1000);
  return () => clearInterval(id);
}, []);

The same applies to event listeners, subscriptions, WebSockets and observers.

Mistake 3: a fetch race condition → wrong data on screen

function Profile({ userId }) {
  const [user, setUser] = useState(null);
  useEffect(() => {
    fetchUser(userId).then(setUser);
  }, [userId]);
  return <p>user {userId}: {user?.name}</p>;
}

In my test, user 1's request takes 300 ms and user 2's takes 100 ms. Click user 1, then quickly user 2. Request 2 finishes first, then request 1 finishes and overwrites it:

user 2: Ada     ❌  (Ada is user 1!)

Fix: ignore stale responses with a flag in the cleanup.

useEffect(() => {
  let ignore = false;
  fetchUser(userId).then(u => {
    if (!ignore) setUser(u);
  });
  return () => { ignore = true; };
}, [userId]);

user 2: Linus   ✅

When userId changes, the old effect's cleanup sets ignore = true, so its late response is thrown away. You can also cancel the request with an AbortController, or use a data library like TanStack Query, which handles this for you.

Mistake 4: useEffect for derived values → an extra render

const [name, setName] = useState("");

useEffect(() => {
  setName(first + " " + last);
}, [first, last]);

This renders twice: first with an empty name, then again with the real one. I logged each render:

renders: 2 → "", "Ada Lovelace"   ❌
renders: 1 → "Ada Lovelace"       ✅

That's a wasted render and a flash of wrong content.

Fix: if you can calculate it from props or state, just calculate it during render.

const name = first + " " + last;

For expensive calculations, use useMemo.

Checklist

No new objects or arrays in the dependency array (or useMemo them)
Started something? Return a cleanup
Fetching? Ignore stale responses (or use AbortController)
Can you calculate it during render? Then you don't need an effect
Strict Mode runs effects twice in development on purpose, to find these bugs

Which of these have you shipped? 😅 Tell me in the comments.

I post one tested coding tip every day on YouTube at Refactorly. The 30-second version of this one is here.

DEV Community: Muiduzzaman Lipu

One Change Made My Python Code 2,000 Faster (Lists vs Sets)

The slow code

The fix: one function call

Why: how in works

Measured: a single lookup at different sizes

When to use a set (and when not to)

Try it on your code

The Python Bug That Fools Everyone: Mutable Default Arguments

Why it happens: defaults are created once

The fix: use None and create the list inside

Same trap, different shape: frozen timestamps

Dataclasses protect you (use default_factory)

Bonus pitfall: items = items or []

Recap

4 useEffect Mistakes Almost Every React Dev Makes (I Ran Them All in React 19)

Mistake 1: an object in the dependency array → infinite loop

Mistake 2: no cleanup → leaks (and a double timer)

Mistake 3: a fetch race condition → wrong data on screen

Mistake 4: useEffect for derived values → an extra render

Checklist

Why: how `in` works

The fix: use `None` and create the list inside

Dataclasses protect you (use `default_factory`)

Bonus pitfall: `items = items or []`