Introduction

You usually can create variables dynamically in many languages, but that is rarely the best design. In most real programs, the safer answer is to use a dictionary, map, object, or list so the dynamic part is the data, not the variable names in your code.

Core Sections

Why dynamic variables are usually a code smell

When people ask for dynamic variable creation, they often have data like item_1, item_2, and item_3 and want matching variable names. That feels convenient at first, but it makes code harder to inspect, refactor, and debug because the set of names exists outside the normal structure of the program.

A container gives you the same flexibility without polluting the namespace.

Use a dictionary in Python instead

1values = {}
2
3for i in range(3):
4    values[f"item_{i}"] = i * 10
5
6print(values["item_2"])

This solves the practical problem cleanly: the names are still dynamic, but they live as keys in data rather than as unpredictable top-level variables. That also makes it trivial to loop over the generated entries, serialize them, and pass them to other functions without inventing reflective access tricks later.

Why globals() and locals() are not the normal answer

Python technically lets you write into globals() in some contexts.

globals()["item_1"] = 42
print(item_1)

But that pattern is usually fragile. It can overwrite existing names, confuse readers, and behave poorly inside functions where locals() is not a reliable writable variable store.

For most application code, using a dictionary is clearer and safer.

The same idea applies in other languages

Dynamic-variable questions usually translate to “I need keyed access to a set of values whose names are discovered at runtime.” Maps or objects are the natural abstraction for that.

This matters because data structures come with iteration, serialization, validation, and introspection support. Dynamically invented standalone variable names usually work against those capabilities instead of helping them.

JavaScript example:

1const values = {};
2for (let i = 0; i < 3; i += 1) {
3  values[`item_${i}`] = i * 10;
4}
5console.log(values.item_2);

That is more maintainable than trying to invent standalone variable bindings dynamically.

Choose the data structure that matches access patterns

A dictionary or map is ideal when names are meaningful keys. A list or array is better when the dynamic part is simply position. An object or dataclass may be better when the structure is known but optional fields vary. When you model the problem this way, your tools for iteration, validation, printing, and testing all start working with you instead of against you.

The question is not “how do I force the language to make variable names.” The question is “what structure best represents runtime-defined data.” That framing usually leads to better code. It also leads to code that teammates can understand without inspecting the interpreter’s namespace at runtime.

Common Pitfalls

• Creating dynamic globals when a dictionary or map would express the same idea more safely.
• Using runtime-generated variable names to store structured data that should really live in a collection.
• Writing to locals() in Python and expecting normal local variables to appear reliably.
• Choosing dynamic variable names because the printed output looks nice rather than because the program structure needs them.
• Making debugging harder by scattering state across generated identifiers instead of one inspectable container.

Summary

• Dynamic variable creation is usually possible, but it is rarely the best design.
• In practice, dictionaries, maps, objects, and lists are the preferred solution.
• Python globals() can create names, but that approach is fragile and should be avoided in normal application code.
• Model runtime-defined names as data keys rather than as runtime-generated variables.
• If you think you need dynamic variables, you probably need a better data structure instead.