Introduction

Creating a list with one value repeated N times is simple in Python, but method choice matters when values are mutable. The popular multiplication syntax is fast and concise, yet it can produce shared references that cause hard-to-diagnose bugs. A safe approach starts by checking value mutability and required object independence.

Fast Pattern for Immutable Values

For immutable values, list multiplication is usually ideal.

1n = 5
2zeros = [0] * n
3names = ["item"] * n
4markers = [None] * n
5
6print(zeros)
7print(names)
8print(markers)

Immutable values include integers, strings, tuples, booleans, and None. Repeating these is safe because in-place mutation is not possible.

Why Mutable Values Need a Different Pattern

List multiplication duplicates references, not deep copies. If the repeated element is mutable, every slot points to the same object.

grid = [[0] * 3] * 3
grid[0][0] = 9
print(grid)

All rows change in that example because each row references the same inner list.

This behavior is one of the most common Python initialization mistakes.

Safe Construction for Mutable Elements

Use a list comprehension to create a new object each iteration.

grid = [[0] * 3 for _ in range(3)]
grid[0][0] = 9
print(grid)

Only the intended row changes because each row is a separate list object.

The same rule applies to dictionaries:

records = [{"status": "new"} for _ in range(4)]
records[0]["status"] = "done"
print(records)

Each dictionary stays independent.

Repeating Custom Objects

Custom class instances follow the same reference rule.

1from dataclasses import dataclass
2
3@dataclass
4class Counter:
5    value: int = 0
6
7shared = [Counter()] * 3
8shared[0].value = 10
9print(shared)  # all entries reflect value 10
10
11independent = [Counter() for _ in range(3)]
12independent[0].value = 10
13print(independent)  # only first entry changed

When independent state is required, create one instance per element.

Use Lazy Repetition When List Is Not Needed

Sometimes you only need repeated iteration, not a materialized list. itertools.repeat is memory-friendly for that case.

1import itertools
2
3for token in itertools.repeat("PING", 3):
4    print(token)

This avoids allocating a full list when values are consumed once.

Validate Repeat Count

Python treats zero or negative multipliers as empty lists.

print([1] * 0)   # []
print([1] * -2)  # []

This is valid language behavior, but in APIs it may hide invalid user input. Add explicit validation when business logic requires non-negative constraints.

1def repeat_value(value, n):
2    if n < 0:
3        raise ValueError("n must be non-negative")
4    return [value] * n

Performance Notes

For immutable values, multiplication is generally faster than list comprehension. For mutable values, correctness is more important than micro-optimizations.

1import timeit
2
3mul_time = timeit.timeit("[0] * 100000", number=3000)
4comp_time = timeit.timeit("[0 for _ in range(100000)]", number=3000)
5
6print(mul_time)
7print(comp_time)

Choose the method that preserves correct semantics first, then optimize if profiling justifies it.

Practical Rule of Thumb

A simple decision rule:

• Immutable repeated value uses [value] * n.
• Mutable repeated value uses comprehension constructor.
• Stream-only repetition uses itertools.repeat.

This rule covers most real code scenarios with minimal risk.

Common Pitfalls

• Using list multiplication with mutable objects and creating shared state.
• Expecting repeated objects to be deep-copied automatically.
• Ignoring input validation for negative repeat counts.
• Building huge lists when lazy iteration would be enough.
• Optimizing syntax choice before confirming correctness requirements.

Summary

• List multiplication is fast and safe for immutable repeated values.
• Mutable values require per-element construction to avoid shared references.
• Custom objects follow the same shared-reference rule as lists and dictionaries.
• Use lazy repetition when you do not need full list materialization.
• Select method based on mutability and usage pattern, not syntax preference alone.