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

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.unifieddiff 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 addendoffilenewlinemarkerstomakepatchhappy keyword arg (probably with a different name:) to difflib.unifieddiff 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.unifieddiff and instead update http://docs.python.org/library/difflib.html#difflib-interface documentation to discuss the issue and show how users of unifieddiff 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