AI-Written Python: A Dictionary Fallback Can Run Even When the Key Exists

Imagine you run a print shop with a small digital catalogue. Most product descriptions are already approved and stored in a Python dictionary. For missing ones, a helper can draft a description for review. An AI assistant writes the lookup as approved.get(sku, draft_description(sku)). You test it on a product with approved copy and get that copy back. The result looks right. The draft helper has still run.

That distinction matters if the helper calls an outside service, reads a file or writes to a review queue. Depending on what it does, the script can incur unnecessary work or stop on an error before returning a description that was available all along. A test that checks only the returned text can miss the problem entirely.

A default value is not an instruction to wait

The Python dictionary reference describes get as returning the stored value for an existing key or the supplied default for a missing one. The language reference on calls explains the other half of the behaviour: Python evaluates the argument expressions before attempting the call. In the example, it runs draft_description(sku) to produce a default value before the dictionary has a chance to decide whether it needs that value.

A literal fallback such as approved.get(sku, 'Description pending') is a different case. The default is already a simple value and there is no drafting operation to run. The short form is useful when the alternative is cheap and has no unwanted effects. When the alternative performs work that should happen only on a miss, the code needs to express that condition.

One readable form for a normal dictionary is approved[sku] if sku in approved else draft_description(sku). Only the chosen branch is evaluated. A full if statement may be clearer if the missing branch also needs to record why the description was missing or send it for approval. Ask the assistant to make the decision easy to find in the code. Saving a line is less useful than making it obvious when a new draft can be created.

Review the caller too. If it has already built the fallback and passed it into a helper function, moving the membership check inside that helper comes too late. Pass the product code and let the missing branch call the drafting function. In a code review, follow the call from the first place the draft is constructed, rather than stopping at the line that chooses which text to return.

Decide what ‘missing’ means before fixing the code

A key can be present with an empty string or with None as its value. Suppose your catalogue uses an empty string to mark a product whose description is intentionally hidden. That product should not receive an automatically generated description just because its value is empty. A membership check distinguishes an existing key from an absent one. A truth test such as approved.get(sku) or draft_description(sku) does something different: it also calls the fallback for values Python treats as false, including an empty string.

The right policy depends on what the values represent. If an empty string means an import failed, you may want a person to inspect the record. If it means ‘do not display copy’, you should preserve it. If your import uses both meanings, give them separate states before automating either. Our article on text flags in AI-written Python shows another case in which a convenient truth test answers a different question from the one a catalogue owner intended.

Also decide whether a generated fallback should be saved. A draft for one missing product might belong in a separate review queue, while the approved dictionary should change only after a person accepts it. Avoid asking for automatic caching or insertion unless that is what you want. Getting a value for this run and changing what a later run treats as approved are separate decisions.

Test the call, not just the copy

Use a tiny test catalogue with made-up products. Replace the real drafting helper with a stand-in that records which codes it receives and returns a harmless sample. Ask for two checks on every test: which description came back, and which calls were made. That lets you see the extra work without sending real product data or invoking an outside service.

• Approved description: The lookup returns the exact approved copy and the drafting helper receives no calls.
• Absent product code: The lookup uses the draft helper once for the expected code and keeps the result in the state you intended for review.
• Present but deliberately blank: The lookup preserves the blank and makes no draft under the shop’s rule.
• Unavailable helper: Make the stand-in raise an error. An approved product should still return its description, while a missing one follows the error handling you agreed.

If the script processes many rows, include repeated product codes. A missing code might need one draft for the whole run or one attempt per row, depending on how the work is organised. State which you expect. That choice belongs in the workflow design rather than in a side effect of a dictionary lookup. Start with these small tests, then review the list of products that would be sent for drafting before letting the script process a full catalogue.

When you review AI-written code, pay attention to what happens on the path that looks uneventful. An approved product returning approved copy is only half the evidence. If a draft is supposed to run on a miss, a successful hit should leave the draft helper untouched.

Sources

• Python 3.13 Language Reference, Calls, on argument evaluation.
• Python 3.13 Library Reference, Dictionary get, on stored values and defaults.