The patch inserts \t character between filename and timestamp in unified 
and context diff headers. 

According to specification by Guido Van Rossum =)
http://www.artima.com/weblogs/viewpost.jsp?thread=164293

And de-facto output from various tools
http://code.google.com/p/python-patch/source/browse/#svn/trunk/doc

And the common sense
--- that it is easier to split	this stuff
+++ than this one into filename + timestamp

--- diff.py Sun Dec 27 16:08:28 2009
+++ trunk/diff.py	Sun Dec 27 15:46:58 2009

I don't think the conditional checks around the timestamps are
necessary. Couldn't you just put the \t directly in the string that gets
yielded? That way the chunk headers always follow the same format.

Conditional checks are required to prevent leaving trailing whitespace in 
filename when date component is not present. Such trailing whitespace may 
confuse patch tools. [1]

[1] http://code.google.com/p/python-patch/issues/detail?id=2

Shouldn't the patch tool handle that? FWIW, both the "svn diff" and *nix
diff utilities produce headers with the parts split by a tab character.

Would the code in example.py work in your tool to handle both tabs and
spaces?

Filenames may contain spaces too.

--- handle dis Sun Dec 27 16:08:28 2009
--- или вот это пон, дек 27 16:08:28 2009

The last line is space separated filename and date in Russian locale. 
Patch tool should handle that, but as you may see it is not always 
possible. That's why difflib modification with \t separator will greatly 
improve interoperability of difflib patches regardless of timestamp 
format.

Stripping trailing whitespace when there is no timestamp serves the same 
purpose. We can assume that patch tools are perfect, but I wouldn't 
write my tool if that was true, so its better to be friendly on difflib 
side and generate the output that won't require more work than necessary 
to use it.

I agree that splitting with a tab character is good, but I think it
should be split by a tab character in every case. 

If the separator is different based on what data is provided, then it
complicates parsing and would have to be explained in documentation that
we provide different header formats.

This patch makes sure filename and date split by tab in every case when 
date is provided.

Is there any reason why you changed some of the examples in the docstrings (e.g. 'Sat Jan 26 23:30:50 1991' -> '1991-01-26 23:30:50')?

It is the same reason as for removing recommendation from docstring to generate timestamps in the format returned by time.ctime(). See issue #7582

The reason is to provide a good usage example.

depends on issue #7583

Refreshed patches - feel free to apply in any order you want.

Convenience link for reviews:
http://codereview.appspot.com/809043/show

These patches are incrementally add features. Feel free to apply one that suits most. Codereview provides more convenient way to review differences between these.

attaching optional patch that removes recommendation to use ctime format for timestamps

Your last patch looks the best to me.  I agree both that a tab should not be emitted if there is no date (which is what git, for example, does), and that ISO 8601 timestamps should be promoted as the preferred format.

As you pointed out, issue 7583 needs to be resolved before this can be applied.

In the meantime it would be nice to add an additional test for the no-tab-if-no-date case.

We could avoid the 7583 problem by making the doctests use NORMALIZE_WHITESPACE and moving the real *tests* into the unittests for the module.  I think that would be a good thing to do anyway.

Added unittest for tab with and without set filedate.
Removed #7583 dependency with NORMALIZE_WHITESPACE.

Great, thanks.  I'll check this in when the branch is unfrozen.

Applied to trunk in r8004 and py3k in r8006.

r80004 and r80006 to be exact. 

Great! Thanks! =)

Yes, thanks for the typo correction.

tag:difflib