List vs tuple.
Mutable or not.

What mutability enables:

Lists:
  → append, extend, insert
  → remove, pop, clear
  → item assignment (lst[0] = x)
  → del lst[i]
  → sort in place
  → reverse in place
  → slice assignment (lst[1:3] = [...])

Tuples:
  → no mutation methods
  → no item assignment
  → no del on items
  → no sort in place (use sorted(t) — returns list)
  → no reverse in place (use reversed(t) — returns iterator)
  → no slice assignment

What immutability enables:

Tuples:
  → hashable (dict keys, set members)
  → thread-safe (no locks needed)
  → signal of intent ("this is fixed")
  → safe as default arguments
  → slight memory/speed advantage
  → can be used as cached keys

Lists:
  → not hashable
  → not safe as default arguments
  → need locks if shared across threads
  → mutable state is fine, but has a cost

The rule:
  Use a list when you need to change the collection.
  Use a tuple when the collection is fixed.
  The type communicates intent.

Why tuples can be dict keys:

  Python's dict uses a hash table.
  To look up a key, it hashes the key.
  Hash requires the value to be immutable —
  otherwise the hash could change after insertion,
  and lookups would break.

  Tuples are immutable → hash is stable → safe as keys.
  Lists are mutable → hash would change → not allowed.

Same logic for set members.
Same logic for frozenset vs set.

Hashability is the foundation of Python's
data structures. Immutability is what makes
hashability possible.

Why lists are bigger:

Lists over-allocate to support append.
When a list grows, Python allocates more space
than needed — usually 1.125x to 1.25x — so
the next append doesn't require a resize.

  [1, 2, 3]  → allocated for 3, room for 3-4
  Append 4   → room already allocated
  Append 5   → resize, allocate ~10 slots

The over-allocation is why lists are ~33% bigger
for small collections.

Tuples are fixed size.
When you create (1, 2, 3), Python allocates
exactly 3 slots. No over-allocation.

The memory difference matters when:
  → You have millions of small containers
  → You're reading a large dataset into memory
  → You're caching many keys

It doesn't matter when:
  → You have a few thousand containers
  → You're processing data incrementally
  → The containers are small relative to
    the objects they hold

For 99% of code, the difference is noise.
Choose based on semantics, not micro-optimization.

The real performance win:

Tuples as dict keys:

  # Using a list as a key — impossible
  cache[[1, 2]] = 'value'  # TypeError

  # Using a tuple as a key — works
  cache[(1, 2)] = 'value'  # OK

  # This is the memoization pattern:
  @cache
  def fn(a, b):  # *args becomes a tuple
      ...

The performance benefit isn't from tuple vs list
memory — it's from being able to use the tuple
as a key at all. That's the real reason.

The three most important cases:

1. Function return values — tuple
   def get_user():
       return 'Alice', 30, 'alice@example.com'
   
   name, age, email = get_user()
   
   Why tuple? Because the return is a fixed
   record. You're not going to append to it.
   Python creates a tuple by default when you
   return multiple values with a comma.
   
   Also: the caller can ignore fields with _:
   name, _, email = get_user()

2. Dict keys — tuple
   cache = {(10, 20): 'Lahore'}
   
   Why? Because lists aren't hashable.
   Tuples are. If you need a composite key,
   you need a tuple.
   
   This applies to:
     - Coordinates
     - Multi-part IDs
     - Cached function arguments
     - Grouping by multiple fields

3. Default arguments — tuple (never list)
   def good(items=()):    # safe
       ...
   
   def bad(items=[]):     # BUG
       items.append(1)    # mutates the default
       return items
   
   The list default is evaluated once and
   shared across all calls. The tuple default
   is safe because it can't be mutated.
   
   The standard fix is None + check:
   def good(items=None):
       if items is None:
           items = []
   
   But tuple-as-default is cleaner when the
   function never mutates the argument.

The tuple is the "safer default."
It's immutable, hashable, and signals intent.
Use it whenever you don't need to change
the collection.

The list is for "collection that changes."
Use it when you're building, accumulating,
sorting, or filtering in place.

Both are correct. The type tells the reader
which one you mean.