This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author trentm
Recipients trentm
Date 2008-02-18.20:16:54
SpamBayes Score 0.06289531
Marked as misclassified No
Message-id <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>
In-reply-to
Content
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?
History
Date User Action Args
2008-02-18 20:16:57trentmsetspambayes_score: 0.0628953 -> 0.06289531
recipients: + trentm
2008-02-18 20:16:57trentmsetspambayes_score: 0.0628953 -> 0.0628953
messageid: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>
2008-02-18 20:16:55trentmlinkissue2142 messages
2008-02-18 20:16:54trentmcreate