AI-Written Python: Decide Which Settings Win

A studio has one set of defaults for exporting video: 1080 pixels high, captions off and a standard filename. Then a client orders a square clip with captions. The studio asks an AI assistant to combine the default settings with the job settings. The export runs, the file opens and the dimensions look right. The captions are missing. The script had the right settings available; it chose the wrong one when two sources disagreed.

A merge can be a perfectly good way to build a job’s settings. But the order of the merge is a decision about whose instruction matters. If a job requests captions, can the default turn them off again? Can an operator override a job’s setting just for this export? Work out those rules first, then check whether the code expresses them. A successful run tells you the program accepted the settings. It cannot tell you which settings the studio intended.

The right-hand value wins

Python 3.9 introduced the dictionary union operator, |. As the 2019 proposal for dictionary union and the Python documentation for dictionaries explain, when a key appears in both dictionaries, the new dictionary gets the value from the one on the right. Keys unique to either side are carried over. That makes the line easy to read once you know what each dictionary represents:

defaults = {"height": 1080, "captions": False}
job = {"width": 1080, "captions": True}

settings = defaults | job
# {"height": 1080, "captions": True, "width": 1080}

settings = job | defaults
# {"width": 1080, "captions": False, "height": 1080}

The width survives either way because only the job supplies it. A preview that checks the frame size therefore misses the mistake. A fixture with different values for the same key catches it. Try the opposite conflict as well: if a default enables captions and a specific job turns them off, False should win under the same rule. An explicit choice to turn something off is different from leaving the field out.

Check whether an override is a value or a group

Suppose the studio groups caption options under one key. The defaults specify whether captions are enabled and a font size. The job supplies a new font size. A plain dictionary union sees one shared key, "caption_options". It replaces that key’s entire value; it does not look inside the two groups and combine their fields.

defaults = {"caption_options": {"enabled": True, "size": 24}}
job = {"caption_options": {"size": 30}}

settings = defaults | job
# {"caption_options": {"size": 30}}

Losing enabled may cause an error or leave the exporter to apply another default. Which outcome occurs depends on the code that consumes the result. Decide whether a job supplies a complete group or is allowed to change individual fields. If it can change just the size, specify that the two caption dictionaries should be merged separately and verify that the enabled flag survives. Be wary of asking for a generic recursive merge before you know what every group needs. A list of approved typefaces, for instance, might need to be replaced in full rather than combined with an older list.

Also distinguish replacement from copying. A new outer dictionary does not automatically make independent copies of its nested objects. If someone edits a nested dictionary that the result shares with the defaults, the change can affect later jobs. MaryChuks.com’s explanation of shared records in shallow copies shows why this deserves its own check. The Python documentation also distinguishes |, which produces a new dictionary, from |=, which updates the left-hand dictionary itself. That difference matters if you reuse the same defaults for the next job.

Make the order testable before the first real export

Write the order in ordinary language before asking for code. A studio might start from its defaults, apply the job’s approved choices and then apply a short list of settings the operator can explicitly change for this run. If captions are a condition of delivery for a particular job, validate that condition on the finished settings. Treat a conflict with that requirement as something to resolve, rather than relying on the last dictionary to enforce it by accident.

• Make two sources disagree. Use the same key with opposite values. Confirm the expected winner and try the reverse values as well.
• Check a missing key separately. Remove the override entirely. Confirm that the default returns, then try an explicit empty value and decide whether it should be allowed.
• Use an incomplete nested group. Check which sibling fields survive. If a second job uses the same defaults, verify that the first job did not change them.
• Review the final result. For settings that affect delivery, show the resolved value and which source supplied it. Compare the exported file with that review before sending it.

This is a small test with a useful payoff. The studio can tell the difference between an export that merely ran and an export that honoured the job. When the code makes the winner visible, the next person can change a setting with confidence about what will happen to the rest.

Give overrides a clear lifetime as well. If the operator turns on a watermark for a preview, that choice belongs to the preview job. Save it with the preview settings if someone needs to reproduce the file. Keep it out of the shared defaults, so the next client’s master does not inherit a mark that no one requested.

Sources

• Python Enhancement Proposal PEP 584: Add Union Operators To dict (created March 2019).
• Python 3.12 documentation: Mapping types and dictionary union.