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