When comparing content with difflib, if the resulting diff covers the
last line of one or both of the inputs that that line doesn't end with
an end-of-line character(s), then the generated diff lines don't include
an EOL. Fair enough.

Naive (and I suspect typical) usage of difflib.unified_diff(...) is:

  diff = ''.join(difflib.unified_diff(...))

This results in an *incorrect* unified diff for the conditions described
above.

>>> from difflib import *
>>> gen = unified_diff("one\ntwo\nthree".splitlines(1),
...                    "one\ntwo\ntrois".splitlines(1))
>>> print ''.join(gen)
---
+++
@@ -1,3 +1,3 @@
 one
 two
-three+trois


The proper behaviour would be:

>>> gen = unified_diff("one\ntwo\nthree".splitlines(1),
...                    "one\ntwo\ntrois".splitlines(1))
>>> print ''.join(gen)
---
+++
@@ -1,3 +1,3 @@
 one
 two
-three
\ No newline at end of file
+trois
\ No newline at end of file


I *believe* that "\ No newline at end of file" are the appropriate
markers -- that tools like "patch" will know how to use. At least this
is what "svn diff" generates.


I'll try to whip up a patch. 

Do others concur that this should be fixed?

Attached is a patch against the Python 2.6 svn trunk for this.

At a glance I suspect this patch will work back to Python 2.3 (when
difflib.unified_diff() was added). I haven't looked at the Py3k tree yet.


Note: This *may* also applied to difflib.context_diff(), but I am not sure.

Here is a new patch that also fixes the same issue in
difflib.context_diff() and adds a couple test cases.

Closed 8702 as a duplicate of this one.  Combining nosy lists.

You mean that this patch sits in here for 2 years already? This suxx.

And nobody added the tag 'easy', because people haven't explicitly requested tracker privileges? That suxx. 

And it won't be in 2.7 because of that.. I am disappointed.

Why this issue is not labeled as 'difflib' related? How are people supposed to find this one?

Trent, the "\ New line..." seems to be feature specific to unified format only. http://en.wikipedia.org/wiki/Diff#Unified_format

Hmm.  Not in my version of diff:  it seems to use '\ No newline at end of file' for both unified and 'normal' diffs.

$ diff --version
diff (GNU diffutils) 2.8.1
Copyright (C) 2002 Free Software Foundation, Inc.
...

$ diff 1.txt 2.txt
2c2
< two
\ No newline at end of file
---
> two

This is really a bug, but why it's not fixed during such a long time?

Since trentm's python_difflib_no_eol.patch patch failed against the current trunk, I modified it to work again, also a patch against py3k.

I think it's arguable whether this is a bug or not.  There's no official specification for the unified diff format that I can find anywhere;  the GNU description at

http://www.gnu.org/software/hello/manual/diff/Detailed-Unified.html#Detailed-Unified

doesn't mention this detail.  The '\ No newline at end of file' is actually unnecessary for these Python functions, since they operate on lists and produce a generator, so it would be needless complication.  And changing this might break existing Python code that manually parses the output of unified_diff or context_diff and doesn't know what to do with a leading '\' character.  (Does such Python code exist?  I don't know.)

I'd suggest adding a keyword argument to the unified_diff and context_diff  functions to enable this feature, leaving it disabled by default.

Marking as a feature request:  I think this is somewhere on the line between bugfix and new feature, but either way 2.7 is too close to release to start messing with something that isn't really all that broken.

For 2.7 (and 2.6, 3.1), there's also the option of updating the documentation to point out this issue.  It would also be worth updating the command-line-interface example in the docs to do this post-processing (i.e., for each line that doesn't end in a newline, add '\n\ No newline at end of file') before calling writelines.

The two latest patch files were missing TestDifflib from run_unittest.  Having shown that the tests failed if test_difflib only was patched, then patch difflib against the 3.1 maintainance and py3k branches, the former passed ok and the latter failed.  Could someone please take a look, at the same time considering Mark D's suggestion about using a keyword argument to the unified_diff and context_diff functions.

Firstly, since this is marked as feature request, I updated the patch against py3k, to fix the problems found by BreamoreBoy.

I feel adding a keyword argument to deal with such a case is not quiet worthy. I'd prefer not fix it for 2.x, and make its behavior consist with svn diff and other similar tools, as trentm said, "tools like "patch" will know how to use."

c.f. some discussion on python-dev here:
http://mail.python.org/pipermail/python-dev/2010-October/104501.html

To sum up the current consensus as I understand it, the missing end of line is clearly a bug, but the addition of “\No newline at end of file” is controversial.  In the current patch, both are changed, so backporting only the first fix to 3.1 and 2.7 will require either agreeing to add “\No newline etc” in those versions too, or make another patch for 3.1/2.7.

I uploaded the patch to http://codereview.appspot.com/3432041/ and made some minor comments.

Updated patch which can apply to current py3k cleanly and with changes follow eric's review comments.

Patch does not look bad.  I re-read the discussion on python-dev, where it was suggested to add a keyword argument to get the old behavior.  Have you considered it?

> I re-read the discussion on python-dev, where it was suggested to add a keyword argument to get the old behavior.  Have you considered it?


IIUC, at the time of that discusstion, 3.2 is pre-beta so the suitable option is to add "\No newline etc" by default and add a keyword to get the old behavior, but now it is for 3.3. I wonder if 3.3 is a chance to totally get rid of the *OLD WRONG* behavior.

I’m not sure whether the compatibility policy would prevent that.  Aren’t there some cases with iterators (not strings) that work fine today without the change?  If so, it should be possible to get the same behavior.

Yes there may be.

Here is the updated patch:

Add a new keyword argument to context_diff() and unified_diff() named "warn_no_newline_at_end". If true, emit "\ No newline etc". It defaults to True, set it to false to get the old behavior. I'm not sure if this name is too long, but I haven't got a better name.

Can we have a review on the updated patch please.

I just bounced off this issue and proposed a work-around for it in Black (https://github.com/psf/black/pull/1897).

Since it wasn't mentioned here earlier, the `\` marker _is_ documented in the GNU Diffutils documentation, under "Incomplete Lines" (https://www.gnu.org/software/diffutils/manual/html_node/Incomplete-Lines.html#Incomplete-Lines), and applies to both Context and Normal diff output formats.