Compare Text with Unified Diffs

Select a timestamp to watch that moment on YouTube.

1. 00:00

   A diff helps a reader answer a simple question: what changed between two versions of a text? If one line is inserted near the top, the later lines move down. Comparing line one with line one, line two with line two, and so on produces noisy results because it mistakes a shift for many edits. Python's `difflib` contains sequence- comparison tools and a function that produces unified diff text similar to familiar code review patches. Today we will reproduce the noisy comparison, inspect which lines are equal, added, or removed, and build a small function that returns a readable unified diff.

2. 00:40

   We will also test the no-change case so the function does not claim an edit where none exists. The demonstration uses in-memory strings, no repository and no shell command. The same reasoning applies to release notes, configuration changes, and a small editor. A diff is a view of changes, not a guarantee that the new text is semantically correct. We still need tests or human review for that. `zip` pairs items by index and stops when the shorter list ends. Once the extra line appears, old `beta` is paired with new `beta-extra`, and old `gamma` is paired with new `beta`. The final new `gamma` is not paired at all.

3. 01:21

   The output makes one insertion look like two replacements, then silently drops the trailing item. There is nothing wrong with `zip`; it does exactly what it promises. It is the wrong model for finding insertions and deletions. We need to align sequences by matching common parts, then describe the gaps between them. A diff algorithm does not simply compare equal row numbers. Also note that a line can appear multiple times, so alignment can be ambiguous. For this tiny example there is a clear answer, but on a large repetitive file different reasonable alignments may produce different-looking diffs. The goal is a useful explanation of the change, not a magical proof of intent.

4. 02:06

   `SequenceMatcher` finds matching blocks and describes the spaces between them with operation codes. Here the first line is equal, one new line is inserted, and the two later lines are equal again. That matches our mental model. We set `autojunk=False` so this small example is not affected by the heuristic that skips very common elements in longer sequences. For ordinary files, the default heuristic is often fine, but it is useful to know it exists. The indices in each operation refer to slices of the old and new lists. If you are building a custom change viewer, these operation codes can drive highlighting.

5. 02:47

   For a human-readable patch, `difflib.unified_diff` does the formatting for us. The point of this diagnostic run is to confirm the alignment before formatting. If the program still claimed that `gamma` was deleted and re-added, we would know the issue was in the comparison, not merely in the display layer. The function feeds two sequences of lines into `unified_diff`. `splitlines(keepends=True)` preserves each line ending so the joined output has normal line breaks. The `fromfile` and `tofile` names are labels for the human reader; they do not open files. The hunk includes surrounding context and marks the new line with a plus sign.

6. 03:29

   Unchanged lines appear without a plus or minus, which helps place the edit. If you see a line beginning with minus, that means the old version contained it and the new version does not. A unified diff is useful in a report or review, but it is still plain text. This function does not apply a patch, and it does not save a file. It only summarizes two strings already in memory. That distinction lets us test the comparison logic independently of file I/O. Try renaming the labels and see that the content comparison remains the same while the headers change. The no-change assertion is an important control.

7. 04:09

   If the text is identical, the diff function returns an empty string rather than a header with a false edit. The next assertions check the intended insertion and guard against the noise from the broken `zip` approach. We do not compare every byte of the diff here; that could make a test overly sensitive to harmless context formatting. Instead, we assert the behavior that matters to our example: one added line and no false removals of `beta` or `gamma`. In a real change viewer, add cases for deletions, replacements, repeated lines, and files without a final newline. If the output will be used as an actual patch, test it with the patching tool you

8. 04:51

   intend to use rather than assuming every display diff is directly applicable. On the lesson page, change the input strings and predict how the hunk will move. The skill to take away is choosing an alignment-aware tool for text changes, keeping line endings deliberately, and testing both a real edit and no edit.