[Python-Dev] opinions on issue2142 ('\ No newline at end of file' to difflib.unified_diff)?
R. David Murray
rdmurray at bitdance.com
Thu Oct 7 16:00:03 CEST 2010
On Wed, 06 Oct 2010 15:53:59 -0700, Trent Mick <trentm at 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
More information about the Python-Dev
mailing list