Python Dict Initialization: Syntax and Use Cases

Python dict initialization is one of the first syntax decisions a developer makes when structuring data, yet the choice between a literal, a constructor call, or a comprehension affects readability, runtime behavior, and maintainability. Python provides several ways to create a dictionary, and each approach fits a different situation. Understanding the differences helps you pick the right one without over-engineering.

Dictionary Literals: The Default Choice

For a fixed set of keys known at write time, the literal form is the clearest option:

config = {
    "host": "localhost",
    "port": 5432,
    "timeout": 30,
}

The literal syntax is direct: the keys and values are visible in one place, and the structure mirrors the data it represents. Since Python 3.7, dicts preserve insertion order, so the literal also communicates the intended ordering of keys. There is no function call involved, and the syntax is the most idiomatic choice for configuration blocks, lookup tables, and any dictionary whose contents are known in advance.

One subtle behavior worth remembering: if a literal contains duplicate keys, the last occurrence wins.

d = {"a": 1, "a": 2}
# d == {"a": 2}

This is rarely intentional, but it can mask a copy-paste error, so it is worth keeping in mind when reviewing generated code.

The dict() Constructor for Dynamic Input

The constructor form accepts keyword arguments, an iterable of key-value pairs, or a mapping:

params = dict(host="localhost", port=5432)

Keyword arguments are convenient, but they impose a constraint: keys must be valid Python identifiers. You cannot use dict("server-port"=8080) because the hyphen is not allowed in an identifier. For string keys that contain spaces, hyphens, or other special characters, the literal form is required.

The constructor also converts an iterable of pairs into a dictionary:

pairs = [("host", "localhost"), ("port", 5432)]
config = dict(pairs)

This is useful when the pairs come from a database cursor, a CSV row, or any sequence of two-element tuples. It also accepts a mapping, which creates a shallow copy:

copy = dict(original)

Note that this is a shallow copy. Nested dictionaries and lists are shared between the original and the copy, so mutating a nested value affects both objects.

Dict Comprehensions for Derived Data

When keys and values must be computed from an iterable, a dict comprehension keeps the logic in one expression:

squares = {n: n * n for n in range(1, 6)}

Comprehensions support filtering on the key or value side:

even_squares = {n: n * n for n in range(1, 11) if n % 2 == 0}

The comprehension is the right tool when the dictionary is derived from existing data, such as building an index from a list of objects:

users_by_id = {user.id: user for user in users}

This pattern is common in request handlers where a lookup by identifier is needed repeatedly. A comprehension is also appropriate when the value requires transformation, like normalizing keys to lowercase.

fromkeys and the Shared-Value Trap

dict.fromkeys initializes a dictionary with the same value for every key:

defaults = dict.fromkeys(["a", "b", "c"], 0)

This is concise for immutable defaults like integers, strings, or tuples. The trap appears when the default value is mutable:

groups = dict.fromkeys(["x", "y"], [])
groups["x"].append(1)
# groups["y"] is also [1]

Because fromkeys stores the same object reference for every key, mutating one entry changes all of them. If each key needs an independent list, a comprehension creates a fresh list per key:

groups = {key: [] for key in ["x", "y"]}

The distinction between sharing a reference and creating a new object is the central reason fromkeys is not a universal shortcut.

Merging Dictionaries at Initialization

Python 3.9 added the merge operator, which makes combined initialization explicit:

base = {"a": 1}
extra = {"b": 2}
combined = base | extra

The result is a new dictionary containing the keys of both operands. When a key appears in both, the right-hand operand wins. The in-place variant updates an existing dictionary:

base |= extra

Before 3.9, the common pattern was unpacking:

combined = {**base, **extra}

The unpacking form still works and is the only option on Python 3.8 and earlier. The merge operator is more readable when the intent is a genuine union of two dictionaries, and it avoids the visual noise of double asterisks.

Runtime Cost and Maintainability Tradeoffs

In CPython, a dict literal is compiled to a single BUILD_MAP bytecode instruction, while the constructor requires a function call. For typical application code, this difference is negligible. The more meaningful cost appears when dictionaries are rebuilt repeatedly in a hot loop. If a loop creates a fresh dictionary on every iteration, the allocation itself is the cost, not the syntax you chose.

Maintainability usually matters more than micro-optimization. The literal form communicates the data structure at a glance. The constructor is appropriate when the input is already a sequence of pairs. A comprehension is the clearest when the dictionary is derived from another collection. Choosing based on what the code expresses, rather than on speculative performance, produces code that is easier to review and modify.

Hashability and Key-Type Pitfalls

Every dictionary key must be hashable. Lists and other mutable containers cannot be keys, which is a common error when initializing from a list of lists:

# TypeError: unhashable type: 'list'
d = dict([["a", 1], ["b", 2]])

The outer list of pairs is fine because each pair is a two-element list, but the inner lists are used as keys and raise a TypeError. Converting the inner pairs to tuples resolves the issue:

d = dict([("a", 1), ("b", 2)])

Another pitfall is mixing integer and string keys that look similar. {1: "one"} and {"1": "one"} are distinct entries, and a lookup using the wrong type silently returns KeyError. When initializing dictionaries that will be looked up by external input, keep the key types consistent and validate them at the boundary.

The practical rule for initialization is to match the syntax to the source of the data: literals for fixed structures, the constructor for pair sequences, comprehensions for derived data, and fromkeys only when the default value is immutable. Each method has a narrow set of situations where it is clearly the best fit, and the shared-value behavior of fromkeys is the one that most often surprises developers in production code.