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 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.
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.
Activity
patena commented on Mar 16, 2012
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 dataIt 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.
merwok commented on Mar 16, 2012
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?
terryjreedy commented on Mar 16, 2012
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.)
patena commented on Mar 16, 2012
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.
elibendersky commented on Jul 15, 2012
ping
terryjreedy commented on Jul 15, 2012
I guess I should try to come up with something that is an improvement, even if not perfect.
elibendersky commented on Jul 17, 2012
I agree. Any improvement is preferred over just letting this decay in the issue tracker ;-)
elibendersky commented on Oct 8, 2013
Tim, any suggestions?
albamagallanes commented on Mar 17, 2014
I would like to help with this issue. I'm attaching a patch for it.
albamagallanes commented on Mar 18, 2014
I removed the References to 2.x version.
akuchling commented on Mar 18, 2014
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.
merwok commented on Mar 19, 2014
amk, if you’re satisfied with your patch, I think you can go ahead and commit it.
elibendersky commented on Mar 19, 2014
Revised patch LGTM.
python-dev commented on Mar 19, 2014
New changeset 0a69b1e8b7fe by Andrew Kuchling in branch 'default':
bpo-14332: provide a better explanation of junk in difflib docs
http://hg.python.org/cpython/rev/0a69b1e8b7fe