AI-Written Python: Compare Events in the Right Order

A workshop asks an AI assistant to write a report on booking changes. The first few rows look convincing: a booking went from requested to confirmed, then from confirmed to cancelled. Further down, the report says a cancelled booking became requested again. The team investigates and finds that those two rows came from different bookings. The script compared neighbours in the file. Everyone reading the report assumed it compared neighbours in one booking’s history.

Before using the number of changes to make a decision, look at how the script builds its pairs. Which record comes next? Must both records refer to the same booking? What happens if the record in between never arrived? Those are questions about the data and the business process. A short Python function can carry out the rule you give it, but it cannot decide what the next row means.

What pairwise actually compares

The Python documentation for itertools.pairwise describes a function, added in Python 3.10, that yields overlapping pairs in input order. With three records, it gives you the first and second, then the second and third. A sequence with fewer than two records yields no pairs. Here is an example using the history of a single fictional booking:

from itertools import pairwise

states = ["requested", "confirmed", "cancelled"]
transitions = list(pairwise(states))

assert transitions == [
    ("requested", "confirmed"),
    ("confirmed", "cancelled"),
]

The middle value appears twice because it closes one comparison and opens the next. That is useful when you want to see each change in a sequence. It would be the wrong approach for a file whose rows are already arranged as independent before-and-after snapshots. In that case, the end of one snapshot must not become the beginning of the next. Ask how the input was produced before asking an AI assistant to pair it.

Find the boundaries before comparing the neighbours

A file might interleave rows from two bookings because changes arrive as they happen. Sorting the entire file by time gives you one timeline for the workshop, but does not give you a timeline for each booking. For a report about individual journeys, separate the rows by booking identifier first. Then order each booking’s events using the field that represents their sequence. Only then compare adjacent records within that booking.

Decide what to do when two events share the same timestamp. Perhaps the source also supplies a sequence number that establishes which happened first. If it does not, a tie may be genuinely ambiguous. Sorting by a convenient label can produce a repeatable answer without making it a true account of what happened. If the distinction matters, keep the ambiguity visible instead of allowing the report to choose silently.

The order of the surviving records also cannot tell you what went missing. Suppose you see requested followed by cancelled. That is the change the report can observe. It does not establish that no confirmation happened between them. Compare the history with the system that records the actual booking if the distinction affects the decision. MaryChuks.com’s guide to arrival order versus event order addresses a related trap: the last record to reach a report can describe an earlier event.

Check the start of the period, too. A Monday-to-Friday report may need the last recorded state from Sunday to recognise the first change on Monday. Simply taking this week’s rows and pairing them will miss that comparison. If Sunday’s state is available, use it as context without counting Sunday’s earlier transitions in the new report. If it is unavailable, say that the first state observed in the period has no known predecessor. This matters for a booking that entered the week already confirmed: its first recorded cancellation should not be mistaken for a booking that never had a confirmation.

Make the reported change prove what it claims

• Include an interleaved fixture. Test two bookings with events mixed together. Confirm that the report never compares a row from one booking with a row from the other.
• Try a single row. A booking with one recorded state has no observed transition. If you also need a count of bookings, compute it separately; a transition count will miss that booking entirely.
• Test a repeat and a gap. Two identical states might count as observations but not as changes. A known missing row should be called out if it prevents you from explaining the sequence.
• Make a transition traceable. Keep enough detail to find the two records behind a result. A reviewer should be able to see the booking identifier, ordering evidence and the states that were compared.

Write the desired report in ordinary language before reviewing the code: compare consecutive recorded states for each booking, in the order supported by the source, and count only pairs whose states differ. That definition still leaves room for a separate report on timing or missing records. It also makes a simple code review possible: check where the script groups, sorts, pairs and counts, and see whether each step respects the meaning you intended.

Try the report against several histories a colleague can verify by hand. Include one booking that never changed, one with a known cancellation and one whose record is incomplete. The examples need not be large. Their purpose is to distinguish a script that can produce pairs from one whose pairs answer a useful question. You can then inspect an unexpected result without assuming it reflects a real change in the workshop.

Source

• Python 3.12 documentation, itertools.pairwise.