[feature request] Support ignore block of code with noqa

[woile]

First of all, thank you so much for this tool, it's fantastic 🚀 !

I would like to request the possibility to support ignoring a block of code. To my surprise, this is a feature some people have needed as well from flake8, see SO question, though it is not supported.

In my current use case, I have a bunch of templates, that are too long, and it becomes cumbersome to add noqa to all of them.

I was wondering if adding something like this would be possible (maybe with a different syntax):

# ruff: noqa: on: E501
TEMPLATE = """
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque sit amet ligula magna. Nulla ${var1} vehicula leo, eget tincidunt leo pharetra in. Ut egestas felis et vehicula commodo. Aliquam ${var2} placerat tortor sed magna faucibus facilisis ut et mauris. Maecenas vitae sem augue. Cras egestas felis nulla, id porta nisl ${var3} vel
"""
# ruff: noqa: off: E501

Suggested changes

• Add section-level suppression/ignoring of rules (ruff: noqa: on and ruff: noqa: off)
• Add scope-level suppression/ignoring of rules (matches pylint block disables)

Thanks!

[charliermarsh]

I'd really like to support something like this. But we may want to couple it with a more holistic redesign of suppression comments. \cc @MichaReiser

[charliermarsh]

And thank you for the kind words :)

[whinee]

Hello, just to add to the already wonderful suggestion, I think also adding a simple and and off switch with just # ruff: noqa: on and # ruff: noqa: off to completely ignore a block of code would be fantastic!

[MichaReiser]

What's your expectation if a file only contains an off comment without a corresponding on comment later in the file?

[whinee]

That the program ignores the lines under that comment.

A markdown linter named markdownlint has that option and if I am not mistaken, if there is no enable comment down the line, then the program just ignores all of it.

This program could also have an option to warn the user when an off flag/comment is unterminated (has no corresponding on switch) cuz disabling linting for the rest of the file is not recommended???? I dont knowwwwwwww

[evanrittenhouse]

I'm pretty interested in this one. Obviously pretty new to the project, but I think that the design proposed above makes sense.

@MichaReiser saw you were mentioned above, are we good to move forward on this design? Do we want to support ignoring multiple rules at once?

[MichaReiser]

@MichaReiser saw you were mentioned above, are we good to move forward on this design? Do we want to support ignoring multiple rules at once?

Technically: I recommend waiting till after #3931 lands because it significantly changes how we handle noqa comments internally.

Regarding the design. I haven't had much time to look into suppression comments, I got sidetracked by figuring out how a setting format could look like in a world where ruff does formatting and linting (and more?).

My personal objective for suppression comments is that we should try to keep it simple. I really like Rust's approach where there's a single way to enable or disable lints: Using allow and deny. The scope is defined by where the attributes are put: In a module -> applies for the whole module, at the top of a function -> applies for the function, at the top of an expression -> applies to the expression. Having a single format keeps things simple and easy to remember. I've had to google ESLint's suppression comment format so many time in the past, got it wrong because I forgot the on comment after disabling a rule for a section, or accidentally deleted the on comment in a refactor 🤭 .

I'm not proposing that we need to implement the same semantics but I think its worthwhile to list the use cases with examples on how the new suppression comments should work. Do we support whole file suppression? Do we want to warn about missing on comments after an off. etc.

[evanrittenhouse]

That makes sense. I'll start working on a design/use-cases - since #1054 asks for block/file-scoped noqa directives, closing this issue should also close that one (file-scoped noqas are already implemented)

[evanrittenhouse]

Editing out the design approach I had here to link to the discussion instead: #4051

[tekumara]

FYI - duplicate of #1289

[adam-grant-hendry]

@woile Thanks for opening this issue!

Per discussion in #3868 , would you please add the following checklist to the beginning of this issue for PR tracking:

• Add section-level suppression/ignoring of rules (ruff: noqa: on and ruff: noqa: off)
• Add scope-level suppression/ignoring of rules (matches pylint block disables)

There are several feature requests to add lint ignoring/suppression capabilities, each with slight variations, and some of the project maintainers have asked to keep track of them here. They may need to be implemented at different times or in several stages, so a checklist would be helpful for tracking to PRs.

Thank you!