Lazy Evaluation Explained: Why Python's map() Gives You an Object, Not a List

You call map(int, ["1", "2", "3"]). You expect a list. You get <map object at 0x7f...>.

You stare at it. You print it. The print confirms that yes, you are holding a weird object. You Google "python map returns object not list" at 11pm and discover you are not alone. There is a word for this. It is called lazy evaluation, and Python did it on purpose.

Eager Evaluation Is What You Expect

Most languages you've used are eagerly evaluated. When you write x = 2 + 3, the CPU computes 5 immediately, stores it in x, and moves on. When you build a list [f(x) for x in data], Python evaluates every f(x) before the list exists.

Eager evaluation means: compute the value the moment the expression appears, regardless of whether you'll use it.

That's the default in Python, JavaScript, Java, C++, and most languages you've touched. It's predictable. You ask for a thing, you get the thing.

squares = [x ** 2 for x in range(1_000_000)]  # Computes all 1M values immediately
print(squares[0])  # You only needed one, but you paid for a million

That list exists fully in memory before you read a single element. The CPU did a million multiplications, you looked at the first result, and the other 999,999 sat there silently judging you.

Lazy Evaluation Defers the Work

Lazy evaluation flips that contract. With lazy evaluation, an expression isn't computed until its value is actually needed.

Python generators are the clearest example:

def squares_gen(n):
    for x in range(n):
        yield x ** 2

gen = squares_gen(1_000_000)  # Nothing computed yet. This is instant.
print(next(gen))               # Computes 0² = 0. Stops there.
print(next(gen))               # Computes 1² = 1. Stops there.

squares_gen(1_000_000) does zero multiplication. It creates a generator object that knows how to produce the next value when you ask. Every next() call runs the function body up to the next yield, pauses, and hands you the result.

You can also write this as a generator expression:

gen = (x ** 2 for x in range(1_000_000))  # Lazy
lst = [x ** 2 for x in range(1_000_000)]  # Eager

One character difference. Parentheses vs brackets. Completely different memory behavior. Python decided this was a good idea and I've decided to agree with it.

The Space Implication Is the One That Matters

The list holds all 1,000,000 integers in RAM simultaneously. On a 64-bit system that's roughly 8 MB just for the integer objects, plus list overhead. The generator holds a single integer at any point, regardless of how many values it might produce.

This is the time-space tradeoff applied to computation itself. The lazy version uses O(1) memory. The eager version uses O(n).

For most interview problems, inputs are small enough that this doesn't matter. But for problems involving streams, large files, or "design a system that processes infinite events," the distinction is the whole answer.

Worth noting: lazy evaluation doesn't improve time complexity. If you eventually consume every element, you do exactly the same total computation either way. What changes is when you do it and whether you ever compute values you don't need.

Python's Built-ins Are Lazier Than You Think

Python 3 made several standard library functions return iterators instead of lists. This trips up engineers who learned Python 2, who then spend 20 minutes confused why their code works differently.

Python 2 (eager)	Python 3 (lazy)
map(f, lst) returns a list	map(f, lst) returns an iterator
filter(f, lst) returns a list	filter(f, lst) returns an iterator
range(n) returns a list	range(n) returns a range object
dict.keys() returns a list	dict.keys() returns a view
zip(a, b) returns a list	zip(a, b) returns an iterator

range(10**9) in Python 3 takes 48 bytes. In Python 2, it would allocate a billion integers. You've been using lazy evaluation every time you write a for loop, and Python never mentioned it.

The catch is that iterators are single-pass. You can iterate through a map() object once, and then it's exhausted. If you need to iterate twice, you need a list or you need to recreate the iterator.

doubled = map(lambda x: x * 2, [1, 2, 3])
list(doubled)  # [2, 4, 6]
list(doubled)  # []  <-- already exhausted

That second empty list has ended more than a few debugging sessions in tears.

Short-Circuit Evaluation Is Lazy Evaluation in Disguise

Here's a form of lazy evaluation you've been using without naming it.

if user is not None and user.is_admin():
    do_something()

Python evaluates user is not None first. If it's False, it skips user.is_admin() entirely. It never calls the method. This is short-circuit evaluation, a specific form of lazy evaluation applied to boolean operators.

The second operand of and is only evaluated if the first is truthy. The second operand of or is only evaluated if the first is falsy.

This isn't just an optimization. It's load-bearing logic. The guard pattern if x is not None and x.value > 0 only works because Python is lazy about the right side. If it eagerly evaluated both sides, you'd get an AttributeError and a much longer afternoon.

In interviews, you'll use this constantly to guard against out-of-bounds access:

if i < len(arr) and arr[i] == target:
    ...

Without short-circuit evaluation, arr[i] would run even when i >= len(arr) and crash. The order of your conditions matters, and now you know why.

Memoization Adds a Cache to the Same Idea

There's a conceptual sibling worth understanding. Memoization is also a form of deferred computation, but with a cache attached: compute lazily (only when needed), then store the result so you never compute it again.

Plain lazy evaluation recomputes the value every time you ask. Memoization computes once and returns cached on every subsequent call.

For pure functions, the two combine into a powerful pattern:

from functools import lru_cache

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

Without the cache, this is O(2^n) in time. With it, each subproblem is computed exactly once. The laziness (only compute when asked) plus the cache (never recompute) gives you O(n) time at the cost of O(n) space for the call stack and cache table. That's the recursion space complexity story playing out exactly as you'd expect.

Four Ways This Bites You in Interviews

Every developer who assumed their generator would still have data on the second pass.

1. Forgetting to materialize an iterator. If the problem expects a list and you return a generator, you'll get a wrong-type answer. Wrap with list(...) when needed. The judge doesn't find the generator as charming as you do.

2. Iterating a generator twice. Two loops over the same generator means the second loop sees nothing. Either convert to a list first or recreate the iterator. This one bites hardest when the first loop is a call to any() or all() and you didn't notice the generator got consumed.

3. Closures capturing variables by reference. The lambda below doesn't capture the value of i at creation time. It captures a reference to i, which ends at 4 after the loop finishes.

funcs = [lambda: i for i in range(5)]
[f() for f in funcs]  # [4, 4, 4, 4, 4]

# Fix: capture by value
funcs = [lambda i=i: i for i in range(5)]
[f() for f in funcs]  # [0, 1, 2, 3, 4]

If you've ever stared at [4, 4, 4, 4, 4] and felt a cold sense of betrayal, this was why.

4. any() and all() exhausting your generator. Both functions short-circuit lazily: any() stops at the first True, all() stops at the first False. Useful, but the generator is left mid-iteration after the call. Any subsequent loop over it starts wherever any() left off, not from the beginning.

How Haskell Took This Further

Python is mostly eager with opt-in laziness via generators. Haskell goes the other direction: lazy by default. Every expression is a "thunk," a suspended computation that only runs when its value is forced.

This lets Haskell programs define infinite lists naturally:

naturals = [1..]       -- an infinite list, never fully computed
take 5 naturals        -- [1, 2, 3, 4, 5]

No looping, no explicit generator. The language never evaluates more of the list than you consume.

Laziness is powerful and dramatically harder to reason about. Thunks accumulate in memory if you're not careful, and debugging is harder because you can't predict when computation happens. TensorFlow originally used lazy evaluation for its computation graphs, then switched to eager execution by default because it made debugging dramatically easier. Turns out "when does this actually run" is a question developers need answered.

For interview purposes, knowing Haskell is lazy by default is enough context. You don't need to write it. But if an interviewer asks about infinite sequences or deferred computation, you now have the vocabulary to sound like you've thought about this before.

When to Pick Lazy Over Eager

Use lazy evaluation (generators, iterators) when you process data sequentially and don't need to revisit it. Use eager evaluation (lists) when you need random access, multiple passes, or the full sequence in memory.

	Eager	Lazy
When computed	Immediately	On demand
Python examples	List comprehension, sorted()	Generator expression, map(), range()
Memory	O(n) upfront	O(1) per element
Time total	Same	Same
Reusable?	Yes	No (single-pass)
Good for	Small data, random access	Streams, large data, infinite sequences

For coding interviews, the practical wins are: memory-efficient iteration over large inputs, clean guard clauses with short-circuit evaluation, and avoiding iterator exhaustion bugs. If you want to practice explaining these trade-offs out loud under time pressure, SpaceComplexity runs voice-based mock interviews where the follow-up questions probe exactly this kind of depth.

Further Reading

• Lazy evaluation, Wikipedia
• Short-circuit evaluation, Wikipedia
• What's Lazy Evaluation in Python?, Real Python
• Python Glossary: generator
• itertools, Python documentation