How can I turn a hard-to-reproduce function bug into a small example?

First, write down one failing call before changing anything: the function name, its arguments, the expected result, and the actual result or error. Keep the function code you suspect is involved, but treat everything else as removable until testing shows otherwise. The goal is not to rewrite the function or make a nicer example; it is to preserve the failure with less surrounding material.

For example, suppose a larger program calls keep_items with data assembled from several steps. If the failure still occurs with a short literal list passed directly to the function, use that list instead. Make one reduction at a time—remove setup, shorten the input, or remove an unrelated statement—and rerun the same call. If the failure stops, undo that particular reduction and try a different one. This makes it easier to see which details are necessary.

Include only what is needed to demonstrate the issue: a short function definition (or the relevant part if the rest is essential), a concrete input, the expected result, and the actual result. A simple check makes the comparison visible. Label expectations as expectations, rather than presenting them as something the code produced.

Here is a deliberately small example. Assume the intended behavior is to keep every item except None; the function below instead drops zero as well:

def keep_items(values):
    return [value for value in values if value]

items = [0, 2]
expected = [0, 2]
actual = keep_items(items)

print("expected:", expected)
print("actual:  ", actual)

For this example, the output is expected: [0, 2] and actual: [2]. The input includes the value that exposes the mismatch, and the stated expectation explains why that value matters. For your own bug, replace these assumptions with the behavior your function is meant to provide.

Keep a copy of the original failing call, then reduce the input in small, reversible steps. Try removing one element, shortening one string, or replacing a complicated value with a simpler one. After each edit, run the same check and compare expected with actual. If it no longer fails, restore the last edit and try another reduction; the removed detail may have triggered the behavior.

Also preserve relationships that may matter, such as repeated values, ordering, or a particular empty or boundary value. Do not silently change the expected result to match the output. If you are unsure whether a detail matters, keep it and note it. A slightly larger example that reliably shows the mismatch is more useful than a tiny example that no longer fails.

Give the example a short label and separate the observed facts from your interpretation. State the expected behavior in plain language, show the minimal call and function code, and report the actual result or exact error text. Mention any remaining assumption—for example, “I expect zero to be retained”—rather than implying that the example establishes why the code behaves that way.

A copyable format is:

Goal: [what the function should do]
Input: [smallest input that still fails]
Expected: [result you intended]
Actual: [result or error observed]
Code: [relevant function and one call]
Reduced by: [what surrounding setup or data was removed]

This format records the failure without claiming a cause. A small reproduction can help focus debugging, but it does not by itself prove which change will fix the original program.