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
`noqa` comments are detect as code #103
This line raises an E800 warning.
# noqa: A100
These do not:
# noqa: 100 # noqa: something # noqa: "Something"
If anything, the second block might be code (like a line of a multi-line dictionary definition). The first block is a valid noqa-comment and should not raise that warning.
@sobolevn Just realized I was using it wrong anyways. The
I cam across this because of the DAR docstring violations when I want to ignore these violations on a multi-line docstring.
def myfunc(): """ Return true, always. Here is some more stuff. # noqa: DAR201 """ return True
This suppresses the specified error
The same is true for multi-line strings.
mystring = """Return true, always. Here is some more stuff. # noqa: DAR201 """
@sobolevn do you still consider this an issue for
Ok, this is our issue indeed. Why? Because we use
Will you please fix it?
I can try and give it a shot…
On 10. Dec 2019, at 01:48, Nikita Sobolev ***@***.***> wrote: Ok, this is our issue indeed. Why? Because we use physical_line https://github.com/sobolevn/flake8-eradicate/blob/master/flake8_eradicate.py#L35 <https://github.com/sobolevn/flake8-eradicate/blob/master/flake8_eradicate.py#L35> instead of logical_line Sorry!
After finally getting
The contribution guidelines say to run
$ mypy wemake_python_styleguide mypy: can't read file 'wemake_python_styleguide': No such file or directory
I assume it should be
$ mypy flake8_eradicate.py Success: no issues found in 1 source file
Is that correct? Should I open another issue to tackle that?
`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`. sobolevn#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.
Not yet. I need to look more into how the interaction with flake8 works. I would need some sort of information about the context of the physical line, e.g to determine if it is inside a docstring. Or a way to tell the FileProcessor not to dump the comment lines. Haven’t found any options on that yet. Also, there is not much documentation on what a logical line is or how that could be configured. Anything you can point out to me would be helpful.…
On Dec 12, 2019, at 21:06, Nikita Sobolev ***@***.***> wrote: Hm, any ideas how this can be solved? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
Source code is always helpful for me: https://github.com/PyCQA/flake8/blob/6cc0abbea2e2f44977c7ac5e75072e0ca20c0831/src/flake8/checker.py#L514
* Add false positive test for noqa comment `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. * Check if comment in physical line before eradicate 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. * Rename function and add docstring 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). * Remove single type annotation Because no other type annotations are used in the method, the one used type annotation breaks the consistency of the method. The type annotation is removed.