List vs Tuple in Python

A list and a tuple holding the same values compare equal, but they are different types with different capabilities.

values = [1, 2, 3]
frozen = (1, 2, 3)

print(values == frozen)          # True - same values
print(type(values).__name__, type(frozen).__name__)   # list tuple

values.append(4)
print(values)                  # [1, 2, 3, 4]

try:
    frozen.append(4)
except AttributeError as err:
    print("AttributeError:", err)

# Tuples are hashable, lists are not
print(hash(frozen) == hash((1, 2, 3)))    # True
try:
    {values: "list key"}
except TypeError as err:
    print("TypeError:", err)

The AttributeError confirms that a tuple has no append method — the mutating methods simply do not exist on it. The dict example shows the second difference: a tuple of hashable values can be a dictionary key, while a list cannot, because it is mutable and its hash would change.

Tuples do have a few methods, just not the mutating ones. count and index work on them, and they support slicing, concatenation and repetition, all of which produce new tuples. They are also smaller and marginally faster to create than the equivalent list, because there is no over-allocation to make room for later appends.

The hashability point deserves a caveat. A tuple is only hashable if all of its contents are hashable, so a tuple containing a list raises a TypeError when you try to hash it. That is the same rule that applies to a frozenset, and it is worth checking when a tuple is used as a dictionary key.

The deciding question is whether the collection will change after you create it. If it will, use a list. If the contents are fixed and the collection is meant to be a value rather than a container you keep editing, use a tuple.

That reasoning covers most real decisions, but there are three secondary reasons to prefer a tuple even when a list would work.

First, hashability. A tuple of hashable values can be a dictionary key or a set member, and it can be compared by value in a way that is cheap. That makes a tuple the right shape for a coordinate, a record key, or a configuration value that you want to be usable as a dict key.

Second, safety. Because a tuple cannot be mutated, passing one to a function guarantees the callee cannot change it. Code that returns a fixed record is clearer when that record is a tuple.

Third, memory and speed. A tuple is a single fixed-size allocation with no spare capacity, so it is slightly smaller and slightly faster to create than a list of the same length.

Two things to avoid. First, using a tuple as a poor substitute for a struct: a tuple of three unnamed values is hard to read, and a NamedTuple or a dataclass gives you named fields with the same immutability and hashability. Second, converting a list to a tuple purely for performance without checking whether you need the mutability — that tends to produce TypeErrors later.

The interview summary is short: list means it will change, tuple means it will not. Everything else is a refinement of that.