DEV Community: Ameer Abdullah

The Complete Guide to Python's for Loop Internals

Ameer Abdullah — Thu, 23 Jul 2026 23:27:00 +0000

Every Python for loop you have ever written relies on a two-step protocol that most developers never see because Python hides it behind clean syntax.

Understanding the protocol turns for loops from black boxes into predictable, traceable mechanisms.

What Python Does With Every For Loop

for item in collection:
    process(item)

Python expands this to:

iterator = iter(collection)
while True:
    try:
        item = next(iterator)
        process(item)
    except StopIteration:
        break

iter() calls collection.__iter__() and returns an iterator object.
next() calls iterator.__next__() and returns the next value.
When the iterator is exhausted, __next__ raises StopIteration and the loop ends.

This is the iteration protocol. Any object that implements __iter__ and __next__ can be iterated.

Why This Matters for Tracing

a = [1, 2, 3]
it = iter(a)

print(next(it))  # 1
print(next(it))  # 2

for item in it:
    print(item)

Output:

1
2
3

The iterator is stateful. After calling next(it) twice manually, the iterator has consumed the first two values. The for loop continues from where the iterator left off and only sees 3.

This is why a generator, once partially consumed, resumes from its current position when you iterate it again.

enumerate: What It Actually Does

colors = ["red", "green", "blue"]
for i, color in enumerate(colors, start=1):
    print(i, color)

Output:

1 red
2 green
3 blue

enumerate(colors, start=1) creates an enumerate object that wraps the original iterator. Each call to next() on the enumerate object calls next() on the inner iterator and returns a tuple of (current_count, value).

The tuple (i, color) in the for loop uses tuple unpacking to assign both values simultaneously.

zip: Combining Two Iterators

names = ["Alice", "Bob", "Carol"]
scores = [85, 92, 78, 95]

for name, score in zip(names, scores):
    print(f"{name}: {score}")

Output:

Alice: 85
Bob: 92
Carol: 78

zip stops when the shortest iterator is exhausted. Carol's 78 is included but the fourth score 95 is dropped because there is no fourth name.

zip_longest from itertools fills with a default value instead of stopping.

The Interview Problem: Custom Iterator

class CountDown:
    def __init__(self, start):
        self.current = start

    def __iter__(self):
        return self

    def __next__(self):
        if self.current <= 0:
            raise StopIteration
        self.current -= 1
        return self.current + 1

for n in CountDown(3):
    print(n)

Trace the execution:

iter(CountDown(3)) returns the object itself because __iter__ returns self.
First next(): current is 3, returns 3, current becomes 2.
Second next(): current is 2, returns 2, current becomes 1.
Third next(): current is 1, returns 1, current becomes 0.
Fourth next(): current is 0, raises StopIteration.

Output:

3
2
1

The Exhaustion Problem

numbers = [1, 2, 3, 4, 5]
evens = filter(lambda x: x % 2 == 0, numbers)

print(list(evens))   # [2, 4]
print(list(evens))   # []

filter() returns a lazy iterator, not a list. After the first list(evens) call consumes all its values, the iterator is exhausted. The second call finds nothing remaining.

This surprises developers who treat filter, map, and zip objects as reusable sequences. They are single-pass iterators.

Practice iteration protocol tracing at pycodeit.com.

Python's Object Model in Depth: Why Two Lines That Look the Same Behave Differently

Ameer Abdullah — Thu, 23 Jul 2026 00:25:00 +0000

Two lines of code. Same variable. Same operator. Completely different behavior.

a = [1, 2, 3]
b = a
b += [4]   # line A
print(a)   # [1, 2, 3, 4]

x = 1
y = x
y += 1     # line B
print(x)   # 1

Line A changes a. Line B does not change x. The only difference is whether the variable holds a mutable or immutable object.

To understand why this happens, you need to understand how Python actually represents variables internally.

Variables Are Not Boxes

The box metaphor is how most introductory programming courses explain variables: a variable is a box that holds a value. You put 5 into the box called x. Later you can replace it with 10.

In Python this metaphor is accurate for immutable types and dangerously misleading for mutable types.

The more accurate model: a Python variable is a name that is bound to an object. The object exists independently of the name. Multiple names can be bound to the same object. Binding a name to a new object does not affect the old object or other names that reference it.

You can inspect this directly:

a = [1, 2, 3]
b = a
print(id(a) == id(b))  # True -- same object, two names

x = 5
y = x
print(id(x) == id(y))  # True -- both point to integer object 5

Both cases start the same: two names pointing to the same object. What happens next depends on whether you mutate the object or rebind the name.

Two Fundamental Operations

Every operation on a Python object falls into one of two categories.

Mutation: the object at a given memory address is modified. All names pointing to that address see the change.

Rebinding: a name is pointed at a different memory address. Other names pointing to the original address are unaffected.

List methods like .append(), .extend(), .sort(), and item assignment lst[i] = x are mutations.

Assignment with = is rebinding.

The += operator is either mutation or rebinding depending on whether __iadd__ is implemented and the object is mutable.

Tracing Through the Object Graph

a = [[1, 2], [3, 4]]
b = a.copy()     # shallow copy
b[0].append(99)
print(a)
print(b)

Output:

[[1, 2, 99], [3, 4]]
[[1, 2, 99], [3, 4]]

a.copy() creates a new outer list. So a and b are different list objects. But the elements inside them are the same inner list objects. b[0] and a[0] both point to the same [1, 2] list.

Calling .append(99) on b[0] mutates that shared inner list. Both a[0] and b[0] reflect the change because they reference the same object.

Draw this as a diagram:

a ---------> [ref_to_inner_1, ref_to_inner_2]
b ---------> [ref_to_inner_1, ref_to_inner_2]
              |
              v
              inner_1: [1, 2]  <-- both a[0] and b[0] point here

Appending 99 to inner_1 changes it to [1, 2, 99]. Both a[0] and b[0] see [1, 2, 99] because both still point to the same object.

How Function Arguments Fit This Model

def process(data):
    data = data + [99]   # rebinding -- creates new list
    return data

def process_mutating(data):
    data += [99]         # mutation -- extends existing list
    return data

original = [1, 2, 3]

result1 = process(original)
print(original)           # [1, 2, 3]

result2 = process_mutating(original)
print(original)           # [1, 2, 3, 99]

When process is called, data is bound to the same object as original. data = data + [99] creates a new list and rebinds the local name data. The original object is untouched.

When process_mutating is called, data += [99] calls list.__iadd__([99]) which extends the existing object. The original object is mutated.

The Practical Debugging Rule

When you see unexpected mutation, ask: is there another name pointing to the same object?

When you see a change not being reflected somewhere, ask: was this a rebinding operation that only affected one name?

These two questions diagnose the vast majority of Python mutation bugs faster than any debugger.

Practice tracing mutation problems at pycodeit.com.

I Asked 20 Python Developers to Trace This Code. 18 Got It Wrong.

Ameer Abdullah — Tue, 21 Jul 2026 20:24:00 +0000

I shared this code with 20 developers ranging from students to people with three or more years of experience. I asked them to write down the output before running it.

18 of them got it wrong.

class Config:
    settings = {}

    def add(self, key, value):
        self.settings[key] = value

c1 = Config()
c2 = Config()

c1.add("theme", "dark")
c2.add("language", "Python")

print(c1.settings)
print(c2.settings)

Take a moment. What do you think both lines print?

What Most People Predicted

The most common answer was:

{'theme': 'dark'}
{'language': 'Python'}

The logic: c1 and c2 are separate objects, so their settings should be separate.

What It Actually Prints

{'theme': 'dark', 'language': 'Python'}
{'theme': 'dark', 'language': 'Python'}

Both instances share the same dictionary. Adding to c2 also affected c1.

Why This Happens

settings = {} is a class variable. It is defined on the Config class itself, not on any instance.

When you write self.settings[key] = value, Python looks up self.settings. It checks the instance's __dict__ first. Finding no settings attribute there, it looks at the class. It finds Config.settings which is the shared dictionary.

It then calls dict.__setitem__ on that shared dictionary. This mutates the shared object. Both c1 and c2 read from the same dictionary so both see all additions.

The Fix: Move to init

class Config:
    def __init__(self):
        self.settings = {}

    def add(self, key, value):
        self.settings[key] = value

c1 = Config()
c2 = Config()

c1.add("theme", "dark")
c2.add("language", "Python")

print(c1.settings)
print(c2.settings)

Output:

{'theme': 'dark'}
{'language': 'Python'}

Moving settings = {} into __init__ creates a new dictionary for each instance. self.settings in __init__ creates an instance attribute that shadows any class attribute of the same name.

Why This Pattern Appears in Interviews

This question reveals whether a candidate understands the difference between class attributes and instance attributes at the level of Python's actual object model.

Writing a class is easy. Understanding how Python resolves attribute access through the instance's __dict__ first and then the class is the underlying knowledge being tested.

The follow-up question is always: "What if settings were a string instead of a dict? Would the behavior be different?"

class Config:
    name = "default"

    def set_name(self, new_name):
        self.name = new_name

c1 = Config()
c2 = Config()

c1.set_name("custom")
print(c1.name)
print(c2.name)

Output:

custom
default

With a string, self.name = new_name creates a new instance attribute on c1 that shadows the class attribute. c2 has no instance attribute so it still reads the class attribute "default".

With a dict, self.settings[key] = value mutates the existing class attribute through the reference. It never creates an instance attribute.

Mutation versus rebinding. The same distinction that explains list and integer += behavior.

For more class tracing problems, try PyCodeIt.

Python Error Messages Are Telling You Exactly What Is Wrong. Here Is How to Read Them.

Ameer Abdullah — Mon, 20 Jul 2026 23:26:00 +0000

Most beginners read a Python error message, see a long red block of text, and go straight to Stack Overflow without understanding what they already have in front of them.

The error message is telling you the exact file, the exact line, and the exact nature of the problem. Once you know how to read the structure, you can diagnose most bugs without searching.

The Anatomy of a Traceback

Traceback (most recent call last):
  File "main.py", line 12, in <module>
    result = calculate(data)
  File "main.py", line 7, in calculate
    return sum(values) / len(values)
ZeroDivisionError: division by zero

This traceback has three parts:

Part 1: "Traceback (most recent call last)" tells you the list you are about to read goes from oldest call at the top to newest call at the bottom. The error happened at the bottom.

Part 2: The stack of function calls that led to the error. Each entry shows the file, line number, function name, and the actual line of code that was executing.

Part 3: The exception type and message. This is the most useful line. ZeroDivisionError: division by zero tells you exactly what happened.

The Five Error Types You See Most Often

NameError means you used a name before defining it or spelled it wrong.

NameError: name 'reslt' is not defined

Check your spelling on the line number shown. Look for typos. Check whether the variable was defined in a scope you can access.

TypeError means you applied an operation to the wrong type.

TypeError: can only concatenate str (not "int") to str

You tried to do "hello" + 5. Python will not implicitly convert types. Use "hello" + str(5) or an f-string.

IndexError means you tried to access a list position that does not exist.

IndexError: list index out of range

The list has fewer elements than the index you used. Check your loop bounds and off-by-one logic.

KeyError means you accessed a dictionary key that does not exist.

KeyError: 'username'

The key 'username' is not in the dictionary. Use .get('username') to return None instead of raising, or check if 'username' in my_dict first.

AttributeError means you called a method or accessed an attribute that does not exist on that type.

AttributeError: 'list' object has no attribute 'keys'

You called .keys() on a list. That method only exists on dictionaries. Check what type your variable actually is at that point in the code.

Reading a Multi-Level Traceback

Traceback (most recent call last):
  File "app.py", line 25, in <module>
    run_pipeline(data)
  File "app.py", line 18, in run_pipeline
    cleaned = clean_data(raw)
  File "app.py", line 10, in clean_data
    return [row.strip() for row in data]
  File "app.py", line 10, in <listcomp>
    return [row.strip() for row in data]
AttributeError: 'int' object has no attribute 'strip'

Reading from bottom to top: .strip() was called on an integer, inside a list comprehension on line 10, inside clean_data, called from run_pipeline, called from the main module.

The diagnosis: your data list contains integers mixed in with strings. The clean_data function assumed all elements were strings and called .strip() on all of them.

You do not need Stack Overflow to find this. The traceback told you everything.

The UnboundLocalError: The Most Confusing Python Error

x = 10

def increment():
    x += 1
    return x

print(increment())

UnboundLocalError: local variable 'x' referenced before assignment

This surprises everyone the first time. x exists as a global so why can't the function use it?

Because there is an assignment to x inside the function (x += 1). Python marks any name that appears on the left side of an assignment as local to the entire function, even lines before the assignment.

So when x += 1 tries to read x on the right side first, Python looks for a local x that has not been assigned yet, hence UnboundLocalError.

Fix: add global x before the assignment, or better, pass x as a parameter and return the new value.

Practice reading and predicting Python errors at PyCodeIt.

Why Python's `is` Keyword Will Betray You If You Trust It for Equality

Ameer Abdullah — Sat, 18 Jul 2026 22:23:00 +0000

This is one of the most commonly misused Python features and it fails silently, which makes it especially dangerous in production code.

a = "hello"
b = "hello"
print(a == b)
print(a is b)

Both print True. Safe, right?

Now try this:

a = "hello world"
b = "hello world"
print(a == b)
print(a is b)

a == b prints True. a is b might print False.

Same code structure. Different result. Here is exactly why.

What is and == Actually Check

== checks value equality. Do these two objects represent the same value?

is checks identity equality. Are these two names pointing to the exact same object in memory?

Two objects can be equal in value while being completely different objects in memory.

String Interning

Python automatically interns some strings. Interning means Python reuses a single object for multiple names with the same value, rather than creating separate objects.

Short strings that look like valid Python identifiers are automatically interned. Longer strings or strings with spaces are not always interned.

a = "hello"
b = "hello"
print(a is b)  # True -- both point to the same interned object

a = "hello world"
b = "hello world"
print(a is b)  # False -- two separate objects (implementation dependent)

The behavior for longer strings is implementation dependent and version dependent. You cannot rely on it.

Integer Caching

Python caches integers from -5 to 256. Integers in this range are always the same object regardless of how many names point to them.

a = 100
b = 100
print(a is b)  # True -- cached integer, same object

a = 1000
b = 1000
print(a is b)  # False -- outside cache range, separate objects

a = 256
b = 256
print(a is b)  # True -- last cached integer

a = 257
b = 257
print(a is b)  # False -- first uncached integer

The Interview Trap

x = None
y = None
print(x is y)   # True -- None is a singleton
print(x == y)   # True

x = []
y = []
print(x is y)   # False -- two separate empty list objects
print(x == y)   # True -- both represent empty lists

The canonical use case for is is checking against None, True, and False. These are singletons in Python. Every None in your program is the same object.

# Correct pattern
if value is None:
    handle_missing()

# Incorrect pattern (works by accident, not by design)
if value == None:
    handle_missing()

The == version works because NoneType.__eq__ is implemented but using is is the semantically correct choice and is what PEP 8 requires.

The Practical Rule

Use == for value comparison in all application code.
Use is only for checking against None, True, and False.
Never use is to compare strings or integers in application code, even if it works in testing.

Practice identity vs equality problems at PyCodeIt.

Python Comprehensions: From Confusing to Crystal Clear in 10 Minutes

Ameer Abdullah — Fri, 17 Jul 2026 19:00:00 +0000

List comprehensions confuse beginners not because they are complex but because they are written in the opposite order from how most people think about them.

Once you learn to read them in the right order, they become faster to understand than the equivalent for loop.

The Reading Order

Do not read a comprehension left to right. Read it in this order:

The for part first: where do the values come from?
The if part second: which values are included?
The expression first: what happens to each included value?

result = [x * 2 for x in range(10) if x % 3 == 0]

Step 1 (for): x takes values 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
Step 2 (if): keep only x where x % 3 == 0: that gives 0, 3, 6, 9
Step 3 (expression): multiply each by 2: 0, 6, 12, 18

Output: [0, 6, 12, 18]

Dictionary Comprehensions Work the Same Way

scores = {"Alice": 85, "Bob": 42, "Carol": 91, "Dave": 67}
passed = {name: score for name, score in scores.items() if score >= 70}
print(passed)

Step 1 (for): name and score take each key-value pair
Step 2 (if): keep only pairs where score is 70 or above
Step 3 (expression): create a new dict with those same pairs

Output: {'Alice': 85, 'Carol': 91, 'Dave': 67}

Set Comprehensions Remove Duplicates Automatically

words = ["hello", "world", "hello", "python", "world", "code"]
unique_lengths = {len(word) for word in words}
print(unique_lengths)

Output: {4, 5, 6} (order may vary, sets are unordered)

"hello" has length 5, "world" has length 5, "python" has length 6, "code" has length 4. The set removes duplicate lengths automatically.

The Nested Comprehension

This is where most people give up, but the reading order works here too.

matrix = [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
flat = [num for row in matrix for num in row]
print(flat)

Read the for clauses left to right, outer to inner:

First for: row takes each sublist: [1,2,3], [4,5,6], [7,8,9]
Second for: num takes each element in the current row
Expression: include num as-is

Output: [1, 2, 3, 4, 5, 6, 7, 8, 9]

The Interview Version

pairs = [(x, y) for x in range(3) for y in range(3) if x != y]
print(pairs)

Outer for: x takes 0, 1, 2
Inner for: y takes 0, 1, 2 for each x
If: exclude pairs where x equals y

Pairs where x != y:
(0,1), (0,2), (1,0), (1,2), (2,0), (2,1)

Output: [(0, 1), (0, 2), (1, 0), (1, 2), (2, 0), (2, 1)]

Generator Expressions: The Memory-Efficient Version

import sys

list_comp = [x**2 for x in range(1000)]
gen_expr  = (x**2 for x in range(1000))

print(sys.getsizeof(list_comp))
print(sys.getsizeof(gen_expr))

Output (approximate):

8856
104

The list comprehension stores all 1000 squared values in memory. The generator expression stores only the recipe for generating them, computing each value on demand. For large sequences, the generator uses a fraction of the memory.

For more comprehension and output prediction practice, visit PyCodeIt.

Generator Internals: Why They Are Lazy and What That Actually Means

Ameer Abdullah — Fri, 17 Jul 2026 13:32:00 +0000

Tracing a generator's execution reveals a fundamentally different way Python can run code.

A generator function looks like a regular function but behaves in a fundamentally different way. Understanding that difference requires tracing through what Python actually does when it executes one.

The Key Difference

A regular function runs to completion when called. A generator function returns an iterator object immediately without running any of its code.

def regular():
    print("regular function running")
    return 42

def generator():
    print("generator running")
    yield 42

r = regular()      # prints "regular function running"
g = generator()    # prints nothing

When you call generator(), Python creates a generator object and returns it. None of the code inside the function has executed yet. The print statement does not run until you ask the generator for its first value.

How yield Suspends Execution

def count_to_three():
    print("about to yield 1")
    yield 1
    print("about to yield 2")
    yield 2
    print("about to yield 3")
    yield 3
    print("generator finished")

gen = count_to_three()

print("calling next the first time")
value = next(gen)
print(f"got {value}")

print("calling next the second time")
value = next(gen)
print(f"got {value}")

Trace the execution:

count_to_three() — creates generator object, no code runs
print("calling next the first time") — prints
next(gen) — generator starts executing
print("about to yield 1") — prints
yield 1 — suspends execution, returns 1 to the caller
print(f"got 1") — prints
print("calling next the second time") — prints
next(gen) — generator resumes from where it stopped
print("about to yield 2") — prints
yield 2 — suspends again, returns 2

Output:

calling next the first time
about to yield 1
got 1
calling next the second time
about to yield 2
got 2

The generator's execution is interleaved with the calling code. It runs up to a yield, suspends, and resumes from exactly that point when asked for the next value.

Generator Exhaustion

def small_gen():
    yield 1
    yield 2
    yield 3

gen = small_gen()

print(list(gen))
print(list(gen))

Output:

[1, 2, 3]
[]

Once a generator has yielded all its values, it is exhausted. Calling next() on an exhausted generator raises StopIteration. list() catches this exception and returns an empty list.

Exhaustion is permanent. You cannot restart a generator. To get the values again you must create a new generator object by calling the function again.

Generator Expressions

gen_expr = (x ** 2 for x in range(5))
list_comp = [x ** 2 for x in range(5)]

print(type(gen_expr))
print(type(list_comp))

print(next(gen_expr))
print(next(gen_expr))

Output:

<class 'generator'>
<class 'list'>
[0, 1, 4, 9, 16]
0
1

The list comprehension computes all values immediately and stores them in memory. The generator expression computes each value only when requested. For large sequences this is a significant memory difference.

The send() Method

def accumulator():
    total = 0
    while True:
        value = yield total
        if value is None:
            break
        total += value

acc = accumulator()
next(acc)         # prime the generator

print(acc.send(10))
print(acc.send(20))
print(acc.send(5))

send() resumes the generator and passes a value that becomes the result of the yield expression.

Output:

10
30
35

This is advanced generator behavior tested in senior-level interviews. The generator receives values from the caller through send(), processes them, and yields results back.

When to Use Generators

Generators are appropriate when you need to process a sequence of values but do not need all of them in memory at once.

Reading a large file line by line, generating an infinite sequence of numbers, processing a data pipeline where each step produces values for the next step — all of these are natural fits for generators.

For small sequences or when you need to access elements by index, a list is more appropriate.

Practice generator problems on pycodeit.com — the hard difficulty level includes several generator tracing problems that test exhaustion, send(), and generator expression behavior.

The Complete Guide to Python Dictionary Behavior in Technical Interviews

Ameer Abdullah — Thu, 16 Jul 2026 12:31:00 +0000

Dictionary ordering, key hashing, view objects, and the iteration traps that catch experienced developers.

Dictionaries are the most used Python data structure in production code and one of the most tested in technical interviews. Most developers use them comfortably but have gaps in their understanding of how they actually work.

Insertion Order Is Guaranteed in Python 3.7

data = {}
data["c"] = 3
data["a"] = 1
data["b"] = 2

print(list(data.keys()))
print(list(data.values()))

Output:

['c', 'a', 'b']
['3', '1', '2']

Since Python 3.7, dictionaries maintain insertion order as a language guarantee. Before that, order was an implementation detail. This is worth knowing because interview questions sometimes try to catch candidates who believe dictionaries are unordered.

Mutating a Dictionary While Iterating

data = {"a": 1, "b": 2, "c": 3}

for key in data:
    if data[key] == 2:
        del data[key]

Output: RuntimeError: dictionary changed size during iteration

You cannot add or remove keys from a dictionary while iterating over it. The safe pattern is to iterate over a copy of the keys:

for key in list(data.keys()):
    if data[key] == 2:
        del data[key]

Or collect keys to delete first:

to_delete = [k for k, v in data.items() if v == 2]
for key in to_delete:
    del data[key]

Dictionary Views

data = {"a": 1, "b": 2, "c": 3}
keys = data.keys()
values = data.values()
items = data.items()

print(keys)

data["d"] = 4

print(keys)

Output:

dict_keys(['a', 'b', 'c'])
dict_keys(['a', 'b', 'c', 'd'])

Dictionary views are live views of the dictionary. They update automatically when the dictionary changes. This surprises developers who expect .keys() to return a static snapshot.

The get() Method Versus Direct Access

data = {"a": 1, "b": 2}

print(data["a"])
print(data.get("a"))
print(data.get("z"))
print(data.get("z", 0))

try:
    print(data["z"])
except KeyError as e:
    print(f"KeyError: {e}")

Output:

1
1
None
0
KeyError: 'z'

data["z"] raises KeyError for missing keys. data.get("z") returns None. data.get("z", 0) returns the default value 0. In interview questions about handling missing keys, knowing all three patterns and when each is appropriate demonstrates practical experience.

Dictionary Comprehension Interview Problems

Problem 1:

data = {"a": 1, "b": 2, "c": 3, "d": 4}
result = {k: v for k, v in data.items() if v % 2 == 0}
print(result)

Output: {'b': 2, 'd': 4}

Problem 2:

keys = ["name", "age", "city"]
values = ["Alice", 30, "London"]
result = dict(zip(keys, values))
print(result)

Output: {'name': 'Alice', 'age': 30, 'city': 'London'}

Problem 3 — The Nested Inversion:

original = {"a": {"x": 1}, "b": {"x": 2}, "c": {"x": 3}}
result = {v["x"]: k for k, v in original.items()}
print(result)

Output: {1: 'a', 2: 'b', 3: 'c'}

The defaultdict Pattern

from collections import defaultdict

groups = defaultdict(list)
data = [("fruit", "apple"), ("vegetable", "carrot"), 
        ("fruit", "banana"), ("vegetable", "broccoli")]

for category, item in data:
    groups[category].append(item)

print(dict(groups))

Output: {'fruit': ['apple', 'banana'], 'vegetable': ['carrot', 'broccoli']}

defaultdict(list) creates a new empty list automatically when accessing a missing key. This avoids the if key not in dict pattern. Interviewers often ask candidates to implement grouping logic and the defaultdict approach signals familiarity with the standard library.

Practice dictionary problems with increasing complexity at pycodeit.com.

What I Learned Reviewing 200 Python Interview Questions

Ameer Abdullah — Thu, 16 Jul 2026 11:50:00 +0000

Patterns, frequency analysis, and the concepts that actually matter for getting hired.

Over several months of building PyCodeIt, I reviewed hundreds of Python interview questions from engineering blogs, technical interview guides, and community-sourced collections.

What I found was that the same concepts appear repeatedly, certain topics are tested far more than their importance in daily coding would suggest, and there is a specific category of question that almost nobody prepares for but that appears in almost every interview.

The Frequency Distribution

If I had to put numbers on the concept distribution across technical Python screens:

Appears in roughly 70 percent of interviews:

List and dictionary operations
Loop behavior and iteration
String manipulation
Basic function arguments

Appears in roughly 50 percent of interviews:

List comprehensions and generator expressions
Default mutable arguments
Scope and closures
Recursion with trace questions

Appears in roughly 30 percent of interviews:

Object-oriented Python and class behavior
Exception handling execution order
Decorators
Generators and iterators

Appears in roughly 15 percent of interviews:

Metaclasses and descriptors
Async and coroutines
C extension behavior
Memory optimization patterns

The takeaway: if you have limited preparation time, the top two tiers cover the vast majority of questions you will encounter.

The Category Nobody Prepares For

Dry-run questions, where you are shown code and asked to predict the output appear in roughly 80 percent of Python technical screens in some form. Yet almost no candidate specifically practices this skill.

Everyone practices writing solutions. Nobody practices reading code under pressure.

This is the gap that makes the difference. A candidate who can write a correct solution but stumbles on "what does this print" questions signals to the interviewer that their understanding is applied but not deep.

A candidate who can both write solutions and confidently predict output signals genuine mastery.

What "Entry Level" Questions Actually Test

Questions labeled as easy or entry level in Python interviews are not testing basic knowledge. They are testing whether you have the misconceptions that most beginners have.

The mutable default argument question is considered easy. The variable scope UnboundLocalError pattern is considered easy. The list aliasing question is considered easy.

These are easy only if you understand Python's execution model. If you do not, they are traps. Interviewers use easy questions to filter candidates who have learned syntax without understanding behavior.

The Follow-Up Question Pattern

One pattern appears in almost every interview regardless of difficulty level: the follow-up that changes one detail.

You answer a question correctly and the interviewer says "what if we changed this list to a tuple" or "what if we added a nonlocal declaration here" or "what if this function is called from a different thread."

These follow-ups are more revealing than the original question. They test whether you genuinely understood the concept or just recognized the pattern.

The way to prepare for follow-ups is not to memorize more answers. It is to understand the underlying mechanism well enough to reason from first principles about any variation.

The Most Underrated Preparation Activity

Reading other people's code and predicting what it does is the most underrated preparation activity for Python interviews.

Not writing code. Not solving algorithm problems. Reading code you did not write and forming specific predictions about its behavior.

This is the core skill that dry-run questions test and it is a skill that compounds. The more code you trace, the faster your pattern recognition becomes. The faster your pattern recognition, the more confidently you can handle novel variations.

PyCodeIt was built specifically to provide this practice at scale, AI-generated problems that are always fresh, always a variation you have not seen before, covering the exact concepts that appear most frequently in real interviews.

Python Exception Handling: Tracing try/except/else/finally Blocks

Ameer Abdullah — Wed, 15 Jul 2026 11:25:00 +0000

The execution order of exception handling blocks is non-obvious and regularly tested in senior interviews

Most developers use try/except regularly. Fewer can predict the exact execution order when you combine try, except, else, and finally in a single block, especially when return statements or nested exceptions are involved.

The Complete Structure

try:
    # code that might raise an exception
except SomeException:
    # runs if SomeException is raised in try
except AnotherException:
    # runs if AnotherException is raised in try
else:
    # runs if NO exception was raised in try
finally:
    # ALWAYS runs, exception or not

The else block is the least known. It runs only when the try block completes without raising any exception. It is useful for code that should run only on success but is not part of the operation you are protecting.

Basic Execution Order Traces

Case 1 — No exception:

try:
    x = 1 + 1
except ValueError:
    print("value error")
else:
    print("else block")
finally:
    print("finally block")

Output:

else block
finally block

The try block succeeds. The except block is skipped. The else block runs. The finally block runs.

Case 2 — Exception raised and caught:

try:
    x = int("not a number")
except ValueError:
    print("value error caught")
else:
    print("else block")
finally:
    print("finally block")

Output:

value error caught
finally block

The try block raises ValueError. The except block catches it. The else block is skipped because an exception occurred. The finally block runs.

Case 3 — Exception not caught:

try:
    x = 1 / 0
except ValueError:
    print("value error")
else:
    print("else block")
finally:
    print("finally block")

Output:

finally block
ZeroDivisionError: division by zero

The ZeroDivisionError is not caught by the except clause. The finally block still runs before the exception propagates.

The return Inside finally

def tricky():
    try:
        return "from try"
    finally:
        return "from finally"

print(tricky())

Output: from finally

This is a genuine interview trap. The finally block executes even when there is a return in the try block. The finally return overrides the try return. This behavior is technically correct but widely considered bad practice.

Exception Chaining

try:
    try:
        x = 1 / 0
    except ZeroDivisionError:
        raise ValueError("converted error") from None
except ValueError as e:
    print(f"caught: {e}")
    print(f"cause: {e.__cause__}")

Output:

caught: converted error
cause: None

raise X from None suppresses the exception chain, meaning the original ZeroDivisionError is not preserved as the cause. Without from None, the original exception would be accessible through e.__cause__.

The Interview Question

def process(data):
    result = []
    for item in data:
        try:
            result.append(10 / item)
        except ZeroDivisionError:
            result.append(None)
        else:
            print(f"processed {item}")
        finally:
            print(f"done with {item}")
    return result

output = process([2, 0, 5])
print(output)

Trace each iteration:

item=2: 10/2 = 5, appended. else runs: "processed 2". finally runs: "done with 2". item=0: ZeroDivisionError. except runs: appends None. else is skipped. finally runs: "done with 0". item=5: 10/5 = 2, appended. else runs: "processed 5". finally runs: "done with 5".

Output:

processed 2
done with 2
done with 0
processed 5
done with 5
[5.0, None, 2.0]

Practice exception handling trace problems at pycodeit.com.

Memoization from First Principles: Building and Tracing a Cache

Ameer Abdullah — Tue, 14 Jul 2026 10:45:00 +0000

Understanding memoization by implementing it manually and watching the cache state change alongside each recursive call.

Memoization is one of those concepts that is trivial to use with functools.lru_cache and poorly understood when asked to implement manually. Building it from scratch and tracing the cache state alongside the call stack produces genuine understanding.

The Problem Memoization Solves

def fib(n):
    if n <= 1:
        return n
    return fib(n - 1) + fib(n - 2)

For fib(5), count the calls:

fib(5)
├── fib(4)
│   ├── fib(3)
│   │   ├── fib(2)
│   │   │   ├── fib(1) = 1
│   │   │   └── fib(0) = 0
│   │   └── fib(1) = 1
│   └── fib(2)
│       ├── fib(1) = 1
│       └── fib(0) = 0
└── fib(3)
    ├── fib(2)
    │   ├── fib(1) = 1
    │   └── fib(0) = 0
    └── fib(1) = 1

fib(2) is computed 3 times. fib(1) is computed 5 times. fib(0) is computed 3 times. For fib(50) this becomes catastrophically slow.

Memoization solves this by caching results and returning them immediately on repeated calls.

Manual Implementation

def memoized_fib(n, cache={}):
    if n in cache:
        return cache[n]
    if n <= 1:
        return n
    cache[n] = memoized_fib(n - 1, cache) + memoized_fib(n - 2, cache)
    return cache[n]

Trace the cache state during memoized_fib(5):

Call	Cache before	Returns	Cache after
fib(5)	{}	(computing)
fib(4)	{}	(computing)
fib(3)	{}	(computing)
fib(2)	{}	(computing)
fib(1)	{}	1	{}
fib(0)	{}	0	{}
fib(2) resolves	{}	1	{2: 1}
fib(1)	{2:1}	1	{2: 1}
fib(3) resolves	{2:1}	2	{2:1, 3:2}
fib(2)	{2:1, 3:2}	1 (cache hit)	{2:1, 3:2}
fib(4) resolves	{2:1, 3:2}	3	{2:1, 3:2, 4:3}
fib(3)	{2:1, 3:2, 4:3}	2 (cache hit)	{2:1, 3:2, 4:3}
fib(5) resolves	{2:1, 3:2, 4:3}	5	{2:1, 3:2, 4:3, 5:5}

The cache hits on fib(2) and fib(3) eliminate the redundant subtree computations entirely.

Building a General Memoize Decorator

def memoize(func):
    cache = {}
    def wrapper(*args):
        if args not in cache:
            cache[args] = func(*args)
        return cache[args]
    return wrapper

@memoize
def fibonacci(n):
    if n <= 1:
        return n
    return fibonacci(n - 1) + fibonacci(n - 2)

print(fibonacci(10))
print(fibonacci.__closure__[0].cell_contents)

Output:

55
{(1,): 1, (0,): 0, (2,): 1, (3,): 2, (4,): 3, (5,): 5, 
 (6,): 8, (7,): 13, (8,): 21, (9,): 34, (10,): 55}

The cache is a dictionary inside the closure. Keys are argument tuples. Each unique input is computed exactly once.

functools.lru_cache

from functools import lru_cache

@lru_cache(maxsize=128)
def fibonacci(n):
    if n <= 1:
        return n
    return fibonacci(n - 1) + fibonacci(n - 2)

print(fibonacci(10))
print(fibonacci.cache_info())

Output:

55
CacheInfo(hits=8, misses=11, maxsize=128, currsize=11)

lru_cache uses a Least Recently Used eviction policy when the cache reaches maxsize. The cache_info() method shows how many hits and misses occurred.

The space-time trade-off in memoization is worth understanding deeply for interview discussions: you are trading memory for computation time. For problems with exponential time complexity and polynomial unique subproblems, memoization converts an intractable problem to a tractable one.

Practice memoization tracing problems at pycodeit.com.

String Immutability in Python and Why It Matters More Than You Think

Ameer Abdullah — Mon, 13 Jul 2026 10:15:00 +0000

Strings cannot be modified in place. Understanding the implications changes how you reason about string-heavy code.

Python strings are immutable. This is stated in every introductory tutorial and genuinely understood by relatively few developers.

Immutability does not just mean "you cannot change a string." It means every string operation that appears to modify a string is actually creating a new string object. This has performance implications, mutation implications, and produces interview questions that trip up developers who have never thought carefully about what immutability means in practice.

The Illusion of Modification

s = "hello"
print(id(s))

s = s.upper()
print(id(s))

s = s + " world"
print(id(s))

Output — three different memory addresses:

140234567890
140234567950
140234568010

Each operation creates a new string object. The name s is rebound to the new object. The original strings become eligible for garbage collection.

String Concatenation in Loops

result = ""
for word in ["Python", "is", "fast"]:
    result += word + " "

print(result.strip())

This works correctly but has a performance problem. Each += creates a new string object. For a loop with 1000 iterations this creates 1000 intermediate string objects.

The efficient pattern:

words = ["Python", "is", "fast"]
result = " ".join(words)
print(result)

str.join() allocates the final string in one operation. For large sequences this is significantly faster.

The Mutation That Is Not Mutation

s = "hello world"
s.replace("hello", "goodbye")
print(s)

Output: hello world

.replace() does not modify s. It returns a new string. This surprises developers who are used to methods modifying objects in place (like list.append()). String methods always return new strings.

The fix:

s = s.replace("hello", "goodbye")
print(s)

Interview Problem

def process(text):
    text = text.strip()
    text = text.lower()
    text = text.replace(" ", "_")
    return text

original = "  Hello World  "
result = process(original)
print(original)
print(result)

Output:

  Hello World  
hello_world

Each operation inside process creates a new string and rebinds the local name text. The original variable in the calling scope still points to the original string object, which is unchanged because strings are immutable.

String Interning

a = "hello"
b = "hello"
c = "hello world"
d = "hello world"

print(a is b)
print(c is d)

Output:

True
False

Python interns short strings that look like valid identifiers. Both a and b point to the same interned string object. Longer strings or strings with spaces are not automatically interned, so c and d may be different objects despite having equal values.

Use == for string equality comparisons. Never use is.

Understanding string immutability is foundational to reasoning about string-heavy code correctly. Practice string tracing problems at pycodeit.com.