AI-Written Python: Check Both Lists Before Pairing Records

The script finishes without an error. Two product prices appear in the output. The formatting looks tidy, and the AI assistant explains that the lists have been combined successfully. Yet the original brief contained three products.

This is a small failure with a practical lesson: successful execution does not establish that every input record survived. When asking AI to write a data-handling script, the treatment of unequal inputs belongs in the brief.

Python’s built-in zip() function offers a clear example. It is useful for pairing corresponding positions in sequences, but its default stopping rule can surprise someone expecting a complete handover. Understanding that rule helps a business owner review the work without needing to become a professional programmer.

What zip() actually combines

The official Python documentation describes zip() as combining corresponding elements from its inputs into tuples. By default, it stops when the shortest input ends. Remaining values in a longer input are not included in the resulting pairs.

Think of two queues being served side by side. The first person in one queue is paired with the first person in the other, then the second with the second. When either queue runs out, default zip() stops pairing.

That behaviour can be intentional. The mistake is using it where the task requires every product, filename or response to have a counterpart, without checking whether that requirement holds.

A fictional catalogue with a missing price

Suppose a creator is preparing a small catalogue. The product identifiers, in order, are P101, P102 and P103. A separate price list contains 12 and 18. These are invented example values, not an actual business’s data.

In Python notation, the lists are ids = ['P101', 'P102', 'P103'] and prices = [12, 18]. Running list(zip(ids, prices)) gives [('P101', 12), ('P102', 18)]. P103 has no resulting pair.

The function has followed its rule. The business requirement has failed if the catalogue was supposed to contain all three products. A report that checks only whether each produced row contains a price would miss the omission, because the incomplete product never reached that report.

For this example, the useful question is therefore not merely whether the two output rows look valid. It is whether the output accounts for the three expected products, including any unresolved price.

Make unequal lengths an explicit error

PEP 618, created on 1 May 2020, specified optional length checking for zip(), targeting Python 3.10. With strict=True, unequal exhaustion of the inputs raises a ValueError. The error arises during iteration when the mismatch is encountered; creating the iterator alone does not perform a complete check.

For the catalogue lists, list(zip(ids, prices, strict=True)) raises that error rather than returning a completed list of two pairs. The missing price becomes something the script must handle deliberately.

For a small, finite catalogue, one possible design is to build the complete list of pairs in memory before writing the output file. If that pairing step fails, the later export step should not run. This is a proposed workflow for this example, not a universal design for large or streaming datasets.

The order of operations matters. In a separate example check, a loop processed the P101 and P102 pairs before strict zip() raised its error. If a real loop were updating an external system on each iteration, an eventual error would not itself undo those earlier updates. Length checking should therefore sit within a deliberate plan for when changes are committed.

Equal length does not establish correct correspondence

Now supply three prices: 18, 12 and 25. The lengths match, so strict zip() produces [('P101', 18), ('P102', 12), ('P103', 25)].

But suppose the intended prices were P101 at 12, P102 at 18 and P103 at 25. The first two values have been swapped. The length check passes because both inputs contain three entries; it does not know which price belongs to which product.

This is why independently sorting or filtering parallel lists needs particular care. In our fictional catalogue, the product list and price list must preserve the same correspondence. If the data comes from separately ordered sources, the better design may be to carry the product identifier with each price and match using that identifier.

That alternative still needs rules for repeated identifiers, absent matches and conflicting prices. Naming a key is the beginning of a matching policy. It does not settle every ambiguous record.

A related issue appears in MaryChuks.com’s guide to keeping each order counted once in AI-written SQL: the structure of a combination can change the records represented in the result.

Give the assistant an acceptance brief

A stronger request for the fictional catalogue would state the expected relationship and the response to a mismatch. For example: combine these product identifiers and prices by corresponding position only because their order is guaranteed; require equal lengths; report an error before exporting if either list has unmatched entries.

Then ask for review examples that challenge the assumption:

• Three identifiers and three correctly ordered prices should produce three correct pairs.
• Three identifiers and two prices should produce an explicit failure before the export stage.
• Two identifiers and three prices should also be rejected.
• Three prices in the wrong order should demonstrate that a length check alone cannot validate identity.

The final case is especially useful for reviewing an AI explanation. If the assistant presents strict zip() as proof that each product has received its correct price, its claim exceeds what the check establishes.

The examples described here were executed in Python 3.12.14. They verified default truncation, strict mismatch errors, processing before an error, and the equal-length reordered case. No catalogue platform was connected and no live prices were changed.

A dependable script makes the intended relationship visible. Specify what must match, decide what happens when it does not, and check completeness before treating a tidy output as finished work.

Sources

• Python documentation: zip() — positional pairing, shortest-input behaviour and strict checking.
• Brandt Bucher, PEP 618 — created 1 May 2020; optional length checking for Python 3.10.