Question bank — Tuples — immutability, use cases

False. Parentheses only group here, so (3) is just the integer 3; the comma makes a tuple, so you need (3,).

True. Tuples are heterogeneous, so ("Asha", 21, 5.6) is perfectly valid — order is fixed but types may differ.

False. + builds a brand-new tuple and rebinds the name t; the old object was never touched, which is why immutability still holds.

False. Only tuples whose items are all hashable qualify; (1, [2]) contains a list, so it stays unhashable and raises TypeError.

Mostly true but nuanced. Tuples carry less overhead and construct slightly faster, but you pick them for immutability and intent, not raw speed.

True. Unpacking matches count exactly; a size mismatch raises ValueError: too many/not enough values to unpack.

Half true. The tuple's slots are frozen, but the list living in a slot can still be mutated — immutability is shallow.

True. The comma alone builds it; Python evaluates 3, 4 to (3, 4).

True. The empty tuple is the one case where parentheses (not a comma) are needed, since there's nothing to comma-separate.

Item assignment overwrites a slot, which tuples forbid; this raises TypeError: 'tuple' object does not support item assignment.

A list is mutable and therefore unhashable, so it can't be a dict key; you get TypeError: unhashable type: 'list'. Use (0, 0) instead.

There's no comma, so the parentheses only group 42; type(single) is int. Write (42,).

AttributeError — tuples have no append (it would mutate); their only methods are count and index.

This one fails with TypeError: replacing the slot is forbidden even though the inner list is mutable. t[1].append(9) would have succeeded.

Unpacking demands equal counts; three names but two values gives ValueError: not enough values to unpack.

No error — the trailing comma silently made x the tuple (5,), so len(x) is 1. A stray comma is a classic accidental-tuple bug.

The dict locates a key by its hash first; if the hash could change after insertion, the entry would be filed under a hash the dict can no longer compute, so it'd be lost forever. See Hashing in Python.

Hashability requires the value never change; tuples of immutable items can't change so their hash is permanent, whereas lists can be edited at any time and would break the equal objects ⇒ equal hashes rule.

The comma packs a and b into a single tuple object, which the caller then unpacks with lo, hi = f() — see Functions — return values.

The right side b, a is evaluated into a temporary tuple before any assignment, so both new values are already captured when the unpacking writes them back.

A coordinate is a fixed record whose identity shouldn't change, and it may serve as a dict key or set element — all needs a list (mutable, unhashable) can't meet.

Because + never edits an existing tuple; it allocates a new one, leaving every original object exactly as it was.

Every other sequence method (append, sort, remove, insert) mutates in place, which immutability forbids; only read-only queries survive.

(5,) is tuple (comma present); (5) is int (comma absent). The comma is the deciding factor.

Yes — (). This is the sole case where bare parentheses (no comma) produce a tuple, because there's nothing to separate.

No — the inner list makes the whole tuple unhashable, so adding it to a set raises TypeError, exactly as with dict keys (Sets — hashing & uniqueness).

No — both simply return the empty tuple (); repeat-by-zero and out-of-range slices are safe read operations, unlike out-of-range indexing which raises IndexError.

t becomes (1, [2, 3, 4]) — legal because only the inner list mutated, not the tuple's slots. It's a common surprise, not an error.

You get the one-element tuple (1,); a trailing comma with a single value is enough to build a tuple without any parentheses.