homepage

According to difflib.ndiff help, the optional linejunk argument is "A function that should accept a single string argument, and return true iff the string is junk." Presumably the point is to ignore the junk lines in the comparison. But the function doesn't appear to actually do this - in fact I haven't been able to make the linejunk argument change the output in any way. 
Expected difflib.ndiff behavior with no linejunk argument given:
 >>> test_lines_1 = ['# something\n', 'real data\n']
 >>> test_lines_2 = ['# something else\n', 'real data\n']
 >>> print ''.join(difflib.ndiff(test_lines_1,test_lines_2))
 - # something
 + # something else
 ? +++++
 real data
Now I'm providing a linejunk function to ignore all lines starting with '#', but the output is still the same:
 >>> print ''.join(difflib.ndiff(test_lines_1, test_lines_2, 
 linejunk=lambda line: line.startswith('#')))
 - # something
 + # something else
 ? +++++
 real data
In fact if I make linejunk always return True (or False), nothing changes either:
 >>> print ''.join(difflib.ndiff(test_lines_1, test_lines_2, 
 linejunk=lambda line: True))
 - # something
 + # something else
 ? +++++
 real data
It certainly looks like an error, although it's possible that I'm just misunderstanding how this should work.
I'm using Python 2.6.5, on Ubuntu Linux 10.04.

Unfortunately Python 2.6 only gets fixes for security bugs now, not regular bugs. Can you reproduce the problem with 2.7 or 3.2?

I reproduced the observed behavior in 3.3.0a.
However, I am rather sure it is not a bug.
In any case, linejunk is not ignored. Passing 'lambda x: 1/0' causes ZeroDivisionError, proving that it gets called.
The body of ndiff(linejunk,charjunk,a,b) is
 return Differ(linejunk, charjunk).compare(a, b)
Differ only uses the linejunk parameter here
 cruncher = SequenceMatcher(self.linejunk, a, b)
SequenceMatcher uses the first parameter, isjunk, in the internal .__chain_b method to segregate (not remove) items expected to be common in order to speed up the .find_longest_match method. Read the docstring for that method (and possibly the code) to see how it affects matching. The main intent of the *junk parameters is to speed up matching to find differences, not to mask differences. It does, however, affect output of the .*ratio methods.
The doc string for ndiff says "The default is None, and is recommended; as of Python 2.3, an adaptive notion of "noise" lines is used that does a good job on its own." That is a good idea.
That said, I think the doc (and docstrings) should explain the notion of "junk" elements and what 'ignoring' them means. In particular, I think a couple of sentences should be added after "The idea is to find the longest contiguous matching subsequence that contains no "junk" elements (the Ratcliff and Obershelp algorithm doesn’t address junk)." The quotes around "junk" indicate that it is being used with a non-standard, module specific meaning. What is it? And what does 'ignore' (used several times later in the doc) mean?
Tim, I think we may need your help here since 'junk' is your label for your concept and I am not sure I understand well enough to articulate it. (For one thing, given that the "common" heuristic was apparently meant to replace at least the linejunk version version of junk, I do not understand why .get_longest_match treats 'junk' and 'common' items differently, other than that the two concepts are apparently not the same.)

Ah, I see. True, the ndiff docstring doesn't actually explain what junk IS - I was just engaging in wishful thinking and assuming it did the thing I wanted. A better explanation would help.

ping

I guess I should try to come up with something that is an improvement, even if not perfect.

I agree. Any improvement is preferred over just letting this decay in the issue tracker ;-)

Tim, any suggestions?

I would like to help with this issue. I'm attaching a patch for it.

I removed the References to 2.x version.

Thanks for your patch! I took it and added some more text describing what junk is, and clarifying that junk affects what's matched but doesn't cause any differences to be ignored.

amk, if you’re satisfied with your patch, I think you can go ahead and commit it.

Revised patch LGTM.

New changeset 0a69b1e8b7fe by Andrew Kuchling in branch 'default':
#14332: provide a better explanation of junk in difflib docs
http://hg.python.org/cpython/rev/0a69b1e8b7fe