Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Resolves Issue #103 noqa comments #106
Example of such a multi-line docstring:
def some_function(): """ Test for noqa comments in docstrings. This function has a multi-line doc string, but no return value is stipulated, while the function defines a return. This would raise DAR201 flake8 violation. To suppress this raise violation the following noqa comment is defined in the docstring. # noqa: DAR201 This noqa comment should not be detected as commented out code. `eradicate` itself does not raise this as a violation. """ return "something"
This kind of
This issue is caused by passing isolated physical lines of code to the
To resolve this issue, while still keeping the checker on one physical line at a time, a preliminary test is introduced that checks if the current physical line contains a comment according to the tokens of the physical line. These tokens are available as input to the plugin from
`flake8-eradicate` raises a violation when a `# noqa` comment is defined inside of a multi-line docstring. `eradicate` itself does not raise this as a violation. It should not be detected as a violation, because it is also normal way to suppress `flake8` violations (like DAR201) in multi-line docstrings. As @sobolevn points out, this is probably related to the use of `physical_line` rather than `logical_line`. #103 (comment) This commit adds a function definition to the `correct.py` fixture that has a multi-line docstring and a `# noqa` comment defined inside of it.
When passing a physical line to eradicate, we need to make sure this line contains a comment (as per Python definition). Otherwise this could lead to documentation or noqa-comments in multi-line docstrings as being interpreted as a comment. This is probably caused by passing a single physical line to the eradicate function `filter_commented_out_code`, while this function expects a whole file as input. When passing a whole files source into the `filter_commented_out_code` can parse the logical structure it self. Since we are removing the context for the `filter_commented_out_code` function, we need to make sure the passed in line actually contains a comment. This is a test, that would usually happen inside of `eradicate` but requires more context. To test if the physical line contains a comment, we can request the `tokens` of the current physical line from `flake8` to be passed in. The tokens allow to pre-check if the physical line actually contains a comment. The eradicate function is only invoked for physical lines that do contain a comment.
The function `_is_equal_source` is renamed to `_contains_commented_out_code`. This change reflects the larger scope that the function now has. The function was previously only checking the difference between the filtered source and the physical line. Now the function also needs to test if the physical line even contains a comment before the line is reduced by the eradicate function. This scope is a bit larger which is reflected in the new name. The previous name `_is_equal_source` was derived from the inner implementation. To me it was not immediately clear why we are testing for "source equality". The new name `_contains_commented_out_code` describes what the function can tell us, but now how it is implemented. The implementation is outside of the concern of the caller. All that the caller is interested in is, if the current physical line contains a comment or not. **Attention** With the change of the name, the logic is also inverted. While `_is_equal_source` was `True` when the original and the filtered line are the same, `_contains_commented_out_code` is `True` when they are different (because the commented code was removed by eradicate).
Pull Request Test Coverage Report for Build 340