Merge Dictionaries and Handle Duplicate Keys

Select a timestamp to watch that moment on YouTube.

1. 00:00

   Two configuration records both have an id field, but one says one and the other says two. If our application is combining independent records, silently taking either number would hide a source-data error. In the first run, the helper is named merge unique yet it uses a syntax that always chooses one value. Predict the result and ask whether it matches the function name. This is a good example of a bug that passes a simple demonstration with disjoint keys. We need a contract for collisions before we choose an operator. Python dictionaries can be combined in several ways, but every combination needs a rule for duplicate keys.

2. 00:41

   The union operator makes a new dictionary and prefers the value on the right when a key appears on both sides. update changes its left-hand dictionary in place and returns None. Neither rule is automatically right for a configuration merge. When duplicates should be rejected, inspect the intersection of keys before combining records. This lesson makes the collision policy part of the function contract rather than a hidden side effect. The terminal shows the left id vanish without a warning. The dictionary still looks valid, so a later calculation may use the wrong record and be hard to trace. The problem is not that union or unpacking is defective.

3. 01:23

   They have a documented right-wins rule. The mistake is using that rule in a function that promises to accept only unique keys. Keep the input dictionaries visible in the editor as we compare alternatives. A short expression can be concise while still hiding a policy decision. The broken helper uses an unpacking merge that silently lets the second dictionary overwrite the first. It looks short and returns the expected shape for disjoint inputs, so a happy-path example misses the problem. Add a shared key and print both the merged result and the original inputs. The collision is visible in the result even though no error was raised.

4. 02:05

   Decide whether the inputs represent defaults and overrides, where right wins is sensible, or independent records, where a collision may indicate a data mistake. Now compare the union operator with update. Union returns a new dictionary and preserves the inputs, while update changes its receiver and returns None. Neither one rejects duplicate keys by itself. The set intersection of key views tells us exactly which keys appear on both sides. We can inspect that collision set before combining data. Notice that we compare keys, not values: two entries can have identical values and still violate a unique-key contract.

5. 02:47

   It is the duplicated identifier that matters here. For independent records, form a set intersection of keys and raise ValueError when it is nonempty. Then use left | right to return a fresh dictionary. Choose one shared key to name in the error; do not sort arbitrary keys because different key types may not be comparable. The method should not mutate either argument. A caller can then correct a duplicate instead of losing one value. This is a policy choice; another named function could deliberately implement right-wins overrides. Avoid one vague merge helper whose behavior changes depending on context.

6. 03:27

   The corrected helper checks for duplicate keys and raises ValueError naming one of them. Only a disjoint pair reaches the union expression. The task requires a new result and unchanged inputs, so we use union rather than update. If your product really wants defaults overridden by user settings, write a separately named function and document right-wins behavior. A single vague merge function should not silently switch policies depending on the calling page. After this run, change the sample to share host and watch the error point to that key. An informative error is useful for both automated tests and users.

7. 04:08

   A set of shared keys has no stable display order, so choose one shared key without promising which one when several collide. Sorting arbitrary hashable keys can fail when their types are incomparable. The condition runs before any combination and before any input mutation. If no keys overlap, the union builds a new dictionary. This is still a shallow copy: mutable values inside the result may be shared with the original dictionaries. This lesson promises not to mutate dictionary containers during the merge, not to deep-copy every nested object. State that boundary if callers may later edit nested lists.

8. 04:49

   For example, if both dictionaries contain separate lists under different keys, the result points to those same list objects. Editing a nested list later affects the input that owned it. A deep copy would require a different contract and extra cost. Keep the merge example focused on key collisions, and make the shallow nature of this operation visible to callers. The final verification uses one successful merge and one deliberate collision. It also prints the original dictionaries so we can see that neither was mutated. Test an empty input next: it should return a fresh copy of the other side. In the browser lesson, solve the practical task and then take the quiz about union,

9. 05:32

   update, and collisions. The durable lesson is that syntax follows policy. First decide whether the right side overrides, whether duplicates are forbidden, and whether mutation is allowed. Then choose the operation whose behavior matches those promises. Test disjoint dictionaries, an empty dictionary, one shared key, mixed key types, and unchanged inputs after both successful and failed calls. Python dictionary keys are hashable, so the intersection is a set operation over keys, not a comparison of values. In modern Python, dictionary insertion order is retained, but an error should not

10. 06:12

    assume every hashable key supports sorting. The practical task returns a new union only when no keys overlap, which keeps its promise easy to verify in the browser console.