Unchanged lines detected as changes with difflib.HtmlDiff

[jeffkaufman]

Bug report

Bug description:

When running HtmlDiff on test_api_result.response.txt test_api_result.expected.txt (reported at jeffkaufman/icdiff#223) unchanged lines are being detected as changes. Here's the setup:

import difflib
a = open("test_api_result.response.txt").readlines()
b = open("test_api_result.expected.txt").readlines()
with open("tmp.html", "w") as outf:
    outf.write(difflib.HtmlDiff().make_file(a,b))

And the results: https://www.jefftk.com/html-diff-output-repro

I don't see these spurious deltas when running diff:

$ diff test_api_result.*
31,32c31,32
<             'latitude': 1,
<             'longitude': 1,
---
>             'latitude': 1.0,
>             'longitude': 1.0,
40c40
<         'meeting_url': '',
---
>         'meeting_url': None,
77,78c77,78
<             'latitude': 1,
<             'longitude': 1,
---
>             'latitude': 1.0,
>             'longitude': 1.0,
86c86
<         'meeting_url': '',
---
>         'meeting_url': None,
...

CPython versions tested on:

3.13

Operating systems tested on:

macOS

[hugovk]

To be clear, this is about difflib reporting a difference in 'region': None, and 'state': None,, which the diff command does not:

[adqm]

It looks like this no longer happens under 3.14.0rc1, at least for this test case:

• results from 3.13.6
• results from 3.14.0rc1

I did a quick git bisect, and cherry-picking these three commits onto 3.13 seems to fix this behavior without breaking anything else:

• 0abf997
• 07df93d
• de19694

It was the last of these that the bisect showed as the reason for the change. I'm not sure whether those commits resolve this in a general sense, though, or just a happy accident for this particular test case (I didn't dig into the code, and the commit messages all seemed to be related to speed rather than behavior).

[adqm]

Actually, looking at de19694:

Some inputs may produce different output, but that's rare, and I didn't find a case where the final diff appeared to be of materially worse quality. To the contrary, by refusing to even consider synching on lines "far apart", there was more easy-to-digest locality in the output.

So I expect it's possible that this could still happen on other inputs.