RetroSearch Browse

Thu Oct 7 16:20:44 CEST 2010 · https://mail.python.org/pipermail/python-dev/2010-October/104507.html

On Thu, Oct 7, 2010 at 00:53, Trent Mick <trentm at 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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2010-October/104507.html below:

[Python-Dev] opinions on issue2142 ('\ No newline at end of file' to difflib.unified_diff)?