Exercises — Dictionaries — key-value pairs, access, methods (keys, values, items, get, update)

• a ✅ valid — string keys, integer values.
• b ✅ valid — integers are hashable, so they make fine keys.
• c ❌ invalid — a list is mutable/unhashable → TypeError: unhashable type: 'list'. A key's hash must never change; a list can change, so Python forbids it.
• d ✅ valid — a tuple is immutable, therefore hashable, therefore a legal key.
• e ✅ syntactically valid but the duplicate key "x" collapses: the later value wins, so e == {"x": 2}. No error, just silent overwrite.

• p["name"] → Ravi (bracket access finds the key directly).
• p.get("city") → None — the key "city" is absent, and .get() returns None instead of crashing.
• p.get("city", "unknown") → unknown — the second argument is the default returned when the key is missing.

Prints the keys: math then sci. Iterating a dict directly yields its keys, never its values. To loop over values use scores.values(); to loop over both use scores.items().

Track it step by step:

1. d["age"] = 20 → {"name": "Asha", "age": 20} (new key created).
2. d["age"] = 21 → {"name": "Asha", "age": 21} (existing key overwritten, not duplicated).
3. d.update({"city": "Pune", "age": 22}) → adds "city", overwrites "age" → {"name": "Asha", "age": 22, "city": "Pune"}.
4. del d["name"] → removes that pair → {"age": 22, "city": "Pune"}.

prices.values() is a view of [10, 45, 300]. sum(...) adds them: $10+45+300=355$. So total == 355. Why .values() and not the dict itself? sum(prices) would try to add the keys ("pen" + "book" + ...) and crash on strings. You must ask for the values explicitly.

.get(ch, 0) returns the current count, or 0 if ch isn't in the dict yet — so the very first time we see a letter we add 0 + 1.

• b: 1
• a: appears at positions 2, 4, 6 → 3
• n: appears at positions 3, 5 → 2

Result: {"b": 1, "a": 3, "n": 2} (insertion order: b, a, n).

Prints ['a', 'b', 'c']. d.keys() returns a dynamic view, not a snapshot copy. When we add "c" after creating v, the view still points at the live dict, so it now shows the new key too. Views are windows, not photographs.

Syntax is identical: d[key] = value. The behaviour differs because of what already exists:

• First line: key "age" is absent → Python creates a new pair.
• Second line: key "age" already exists → Python overwrites the value.

This is forced by the rule that keys are unique: assigning to an existing key can only replace, never duplicate. The dict has no way to hold two "age" entries.

• A — no error, prints 1.
• B — raises KeyError ('y' not present). Bracket access on a missing key crashes.
• C — no error, prints None. .get() is the gentle version.
• D — raises TypeError: unhashable type: 'list'. A list cannot be a key.

d = {"a": 1, "b": 2, "c": 3}
inv = {}
for k, v in d.items():
    inv[v] = k
# inv == {1: "a", 2: "b", 3: "c"}

We use .items() to grab both pieces at once, then store value → key in a fresh dict. Caution: this only works cleanly if the values are unique and hashable. If two keys shared a value, one would overwrite the other. One-liner version: inv = {v: k for k, v in d.items()}.

merged = dict(a)        # copy so 'a' is untouched
merged.update(b)        # b's values win on collisions

"sci" appears in both; update lets b's value (95) overwrite a's (80). Final: {"math": 70, "sci": 95, "eng": 88}. (Python 3.9+ one-liner: merged = a | b.)

Counting: m→1, i→4, s→4, p→2. So counts == {"m": 1, "i": 4, "s": 4, "p": 2}. max(counts, key=counts.get) scans the keys and compares each by its count. Both i and s tie at 4; max returns the first one it encountered at that maximum, which is "i" (it appears before s in insertion order). So top == "i".

False. A list lookup scans element by element → time grows with size → $O(n)$. A dict computes hash("Asha") → an address in the hash table → reads the value there directly. That computation costs the same whether the dict holds 5 or 5 million entries → average $O(1)$, independent of size. See Big-O Notation — time complexity. (See the figure below.)

"d" is the last key, at index 3, so the loop compares keys[0], keys[1], keys[2], keys[3] → 4 comparisons. In general the worst case (key at the end, or absent) needs $n$ comparisons → $O(n)$. A dict replaces this whole scan with one hash computation and a direct read → $O(1)$ on average. That is why the syntax d[k] exists: the parallel-list pattern, made automatic and fast.

Two different keys can hash to the same address — a collision. Python stores such keys together at that slot and must check them one by one. If many keys collided, a lookup could degrade toward $O(n)$ in the theoretical worst case. In practice Python uses good hash functions and resizes the table so collisions stay rare, keeping the average cost $O(1)$. The figure contrasts the clean single-slot hit with a small collision chain.

Dict lookup average complexity? ::: $O(1)$ via hash table d.get("z") when "z" absent? ::: returns None (no crash) {"a":1,"a":2} becomes? ::: {"a": 2} (later value wins) for x in d yields? ::: keys Merge b into a? ::: a.update(b) (b overwrites shared keys) Are views copies? ::: no — live/dynamic views