Bug 2957 #3076
Bug 2957 #3076
Conversation
…place where it is run for multilines
…red when deactivating line-too-long message.
…tivated and the test of equal sign presence is move inside it
…ethod anymore but directly inside the check_lines method
…pe of specific_splitlines method
…option_from_lines
…option_from_lines
…me specific keywords that do not require messages
… the pragma_parser module
…uire message. Add a fonction to test emission of exception in case of an unknown keyword with no assignment nor message
|
@PCManticore no need to review this yet. I have still some corrections to make. |
|
@PCManticore i think i have finished this work. I have moved the doc toward 2.5 section and thus deleting the corresponding doc in the 2.4 section. |
There was a problem hiding this comment.
Overall looks great, thank you for the hard work @hippo91 ! Left a bunch of minor comments, let me know what you think.
pylint/utils/pragma_parser.py
Outdated
| super(PragmaParserError, self).__init__(self.message) | ||
|
|
||
|
|
||
| class UnknownKeyword(PragmaParserError): |
There was a problem hiding this comment.
Let's append Error to these exceptions to be more obvious that they are exceptions.
pylint/utils/pragma_parser.py
Outdated
| if not assignment_required: | ||
| if action: | ||
| # A keyword has been found previously but doesn't support assignement | ||
| raise UnsupportedAssignment( |
There was a problem hiding this comment.
I wonder if we need all these exceptions or if we should raise the same exception but with a corresponding message for each situation. My reasoning is that nobody will need to handle all these exceptions to verify that a pragma is broken and will result to handle just the uppermost base class. What do you think?
pylint/utils/pragma_parser.py
Outdated
|
|
||
|
|
||
| ATOMIC_KEYWORDS = ("disable-all", "skip-file") | ||
| MESSAGE_KEYWORDS = ("disable-msg", "enable-msg", "disable", "enable") |
There was a problem hiding this comment.
This can be a frozenset:
| MESSAGE_KEYWORDS = ("disable-msg", "enable-msg", "disable", "enable") | |
| MESSAGE_KEYWORDS = frozenset(("disable-msg", "enable-msg", "disable", "enable")) |
pylint/lint.py
Outdated
| self.add_message( | ||
| "bad-option-value", args=msgid, line=start[0] | ||
| ) | ||
| except (UnknownKeyword, UnsupportedAssignment) as err: |
There was a problem hiding this comment.
Ah I see now where we need all these exceptions. It looks to me though that two should be enough, one to convey the error for a valid, but unrecognized option, and another for a completely invalid pragma.
There was a problem hiding this comment.
I agree with you @PCManticore . The changes have been done.
| @@ -0,0 +1,90 @@ | |||
| import pytest | |||
There was a problem hiding this comment.
I'm not sure if we run black over the tests directory but it seems like this file could be formatted, especially the imports.
There was a problem hiding this comment.
Done! I did it thanks to black and isort.
…nError and InvalidPragmaError
|
@PCManticore i did the change you requested. The CI seems to be blocked on continuous-integration/appveyor/branch and i can't get any infos to understand why. Have you got an idea? |
|
@hippo91 I have no idea as well, it seems to be a misconfiguration of AppVeyor somehow, but I wasn't able to disable that particular check from AppVeyor. I'll give it another go as it is a bit frustrating that it appears for every PR. |
Steps
doc/whatsnew/<current release.rst>.Description
This PR is an answer to #2957. It allows the
line-too-longmessage to be disabled for multilines string such as docstring for example.With this PR if a
pylint:disable=line-too-longpragma is present at the end of a docstring then it is valid for the entire docstring.Eventually if this modification is not judged usefull, i will make another PR that will just reformat the
check_linesmethod insidepylint/checkers/formatmodule because i had some difficulties to read and understand it.Type of Changes
Related Issue