-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pylint inline comments wrapped to wrong line #2843
Comments
Thanks for submitting! We'll have to consider if there's a reasonable way for us to recognise where the comment should go. But failing that, I'd advise to move the comment by hand. Unsatisfying, I know, and annoying if the line is later changed and collapsed back. Dealing with meaningful comments is pretty hard 😄 particularly when splitting lines. If you have any ideas, please share. For the time being, I can't think of anything other than exactly knowing what each comment means and trying to target the correct line. But I'm guessing a = (
inValidName := value # pylint: disable=invalid-name
) And if this is the case, I'd be inclined to not even try to do anything 😅 |
Note that we already special case pylint comments: https://github.com/psf/black/blob/main/src/black/comments.py#L266. Perhaps that can be improved, but as @felix-hilden says, it's very hard to make this perfect because we don't know what the comment refers to. |
just an alternative, make it configurable to prevent formatting on lines with pylint definitions on them? |
One improvement to the handling of those special cased pragma comments I can see is, when the comment is after a closing paren and when it reformats the statement to put the closing paren on its own line, move the comment to after the opening paren instead of the closing paren. This solves the case for comment #1, not comment #2. But this is still going to be a good improvement to make. AFAIK, the comment after the closing paren on its own line will never have any effect (true for Bonus: also include closing paren + comma (
|
This issue has affected me on multiple occasions when invoking black on functions that use |
Oh, and it looks like the issue is even more complicated. This run indicates that putting the noqa comment after the open parenthesis isn't adequate in some cases. It turned out that I needed the |
…ion 6.0.0 Jason R. Coombs (12): Ran pre-commit autoupdate Use '-dev' for every Python version. Ref actions/setup-python#213. Use Python 3.11 for cutting releases. Combine common elements of compare() Add doc test capturing expectation when an empty word is passed. Ref #157. Expected error is a pydantic ValidationError Define a word as a string of one or more characters and validate that assumption in .compare. Fixes #157. Apply validation on other compare* methods. Update changelog. Additionally validate words in other public methods. Manually move the comment after reformatting by black. Ref psf/black#2843. Include the noqa twice, once for Python 3.7 and again for later Pythons.
We are agreeing that Black can't know the perfect location of the pragma, but I do think we are able to statistically improve the heuristic here. To get to a better heuristic, I collected some data from our internal code base for I have a local patch to Black to move the pragma to different places:
We use 80 column limit. Since the code base is mostly lint free, to simulate what happens when Black reformats the line that's too long, I did the formatting using a 60 column limit. I collected 6333 files that has exactly one line that:
After formatting, here are the number of cases that don't work:
These numbers are of course biased towards our own code base and Pylint, and I don't have a good idea for That being said, I'd like to propose:
Thoughts? |
@yilei I was wondering though, if you are indeed going to special case Thanks again for the thorough investigation and getting back to us in our own repo. Much appreciated! @Pierre-Sassoulas Tagging you as you might be interested in this issue |
I'm guessing this is not something that would be accepted by the black team (because this is so pylint specific) but automatically changing I.e. this: asdf = namedtuple('nameoftuplegoeshere', 'fieldsgohere andnoather andanother morehere') # pylint: disadble=invalid-name Could become this: # pylint: disable-next=invalid-name
asdf = namedtuple("nameoftuplegoeshere", "fieldsgohere andnoather andanother morehere") This does not solve the case where the line is still too long of course. But it could diminish greatly what the percentage of case that don't work really amount to in @yilei's data. The pylint comment is taking 20 characters without even specifying the message to disable, so I have the intuition that a decent percentage of lines would be of acceptable length without it. I could work on this if this is a desirable change. |
I would favor @yilei's |
I encountered this issue again today in pypa/setuptools@8c21342. That diff was created by running a recent black. On line 859 (original line 786), there's a |
Pylint inline comments on wrong line after wrapping long line.
Inline comments that trail a command continue to trail the command after black wraps a long line onto multiple lines. While seemingly consistent with the original form, this makes inline comments like #pylint: disable=invalid-name ineffective since they are not on the first line of the command. For example:
becomes
For pylint to work properly, it needs to be:
Since the #pylint comment is no longer on the same line as
asdf =
it does not suppress the pylint warning, changing the behavior of the comment.While not technically a bug, and not changing the functionality of the code, it does have an undesirable effect. Is there some philosophy I'm missing, or is there a recommendation for how to handle this?
The text was updated successfully, but these errors were encountered: