[Python-Dev] opinions on issue2142 ('\ No newline at end of file' to difflib.unified_diff)?
Soliciting opinions on issue 2142 (http://bugs.python.org/issue2142). There are patched available so this isn't vapour. :) The issue is this (I'll discuss only unified_diff(), but the same applies to context_diff()): 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 Where as with `diff`, `hg` and `git`: diff -r 667b0870428d a --- a/a Wed Oct 06 15:39:50 2010 -0700 +++ b/a Wed Oct 06 15:40:31 2010 -0700 @@ -1,3 +1,3 @@ one two -three \ No newline at end of file +trois \ No newline at end of file While originally marked as a *bug*, the issue was changed to be a *feature* request, because arguably `difflib.unified_diff()` is fine, and the problem is in the naive use of the following to create a patch that will work with `patch`: ''.join(gen) Possiblities: 1. Change `difflib.unified_diff` to emit: ['--- \n', '+++ \n', '@@ -1,3 +1,3 @@\n', ' one\n', ' two\n', '-three\n', '\ No newline at end of file', '+trois\n', '\ No newline at end of file'] instead of: ['--- \n', '+++ \n', '@@ -1,3 +1,3 @@\n', ' one\n', ' two\n', '-three', '+trois'] for this case. 2. Add a `add_end_of_file_newline_markers_to_make_patch_happy` keyword arg (probably with a different name:) to `difflib.unified_diff` to do this additional handling. The reason is to not surprise existing code that would be surprised with those \No newline at end of file entries. 3. Not touch `difflib.unified_diff` and instead update http://docs.python.org/library/difflib.html#difflib-interface documentation to discuss the issue and show how users of unified_diff should handle this case themselves. Thoughts? Orthogonal: *After* a decision is made for the Python 3.3 tree we can discuss if including this in either of Python 2.7 or 3.2 would be wanted. -- Trent Mick ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] opinions on issue2142 ('\ No newline at end of file' to difflib.unified_diff)?
On Wed, 06 Oct 2010 15:53:59 -0700, Trent Mick tre...@gmail.com wrote: Soliciting opinions on issue 2142 (http://bugs.python.org/issue2142). There are patched available so this isn't vapour. :) [...] Possiblities: 1. Change `difflib.unified_diff` to emit: ['--- \n', '+++ \n', '@@ -1,3 +1,3 @@\n', ' one\n', ' two\n', '-three\n', '\ No newline at end of file', '+trois\n', '\ No newline at end of file'] instead of: ['--- \n', '+++ \n', '@@ -1,3 +1,3 @@\n', ' one\n', ' two\n', '-three', '+trois'] for this case. 2. Add a `add_end_of_file_newline_markers_to_make_patch_happy` keyword arg (probably with a different name:) to `difflib.unified_diff` to do this additional handling. The reason is to not surprise existing code that would be surprised with those \No newline at end of file entries. 3. Not touch `difflib.unified_diff` and instead update http://docs.python.org/library/difflib.html#difflib-interface documentation to discuss the issue and show how users of unified_diff should handle this case themselves. Thoughts? I don't think (1) is a good option both for backward compatibility reasons and (as mentioned in the ticket IIRC) because not all programs using difflib use it to generate diffs for direct output. (2) might be worth it given that there is a standard to follow so it might be worth coding that standard into the stdlib. Orthogonal: *After* a decision is made for the Python 3.3 tree we can discuss if including this in either of Python 2.7 or 3.2 would be wanted. (3) is the only option for 2.7/3.1. We're still pre-beta on 3.2, so (2) is still an option there. 3.3 doesn't enter the discussion until after 3.2 beta 1. -- R. David Murray www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] opinions on issue2142 ('\ No newline at end of file' to difflib.unified_diff)?
On Thu, Oct 7, 2010 at 00:53, Trent Mick tre...@gmail.com wrote: 1. Change `difflib.unified_diff` to emit: ['--- \n', '+++ \n', '@@ -1,3 +1,3 @@\n', ' one\n', ' two\n', '-three\n', '\ No newline at end of file', '+trois\n', '\ No newline at end of file'] instead of: ['--- \n', '+++ \n', '@@ -1,3 +1,3 @@\n', ' one\n', ' two\n', '-three', '+trois'] for this case. 2. Add a `add_end_of_file_newline_markers_to_make_patch_happy` keyword arg (probably with a different name:) to `difflib.unified_diff` to do this additional handling. The reason is to not surprise existing code that would be surprised with those \No newline at end of file entries. 3. Not touch `difflib.unified_diff` and instead update http://docs.python.org/library/difflib.html#difflib-interface documentation to discuss the issue and show how users of unified_diff should handle this case themselves. Mark (in the issue) argues that there is no specification for diffs, and that this is thus a feature, not a bug. On the other hand, in Mercurial we've maintained the idea that diffs are specified by whatever (GNU) patch(1) accepts. So I would support treating this as a bug, not just a feature. As such, I think 3.2 should emit the extra line by default and add a keyword argument to make it easy to revert to the old behavior (and add docs to 2.7, 3.1 and 3.2 about the issue!). Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
