ignore concrete linting warnings via GUI, e.g. via QuickFix

[VladimirFokow]

Current problem

Sometimes, for example, for a new library, their syntax may still be not integrated in pylint, so the only way to get rid of the warnings is to disable them in settings (JSON).

But it can be hard to know exactly what to write there.

I propose for example, when the user hovers over the linting warning in VSCode, and clicks "Quick fix", there can be an option "Ignore linting like this" which would automatically write to the settings (JSON) this specific case.

(Like the feature "Remember spelling" in some spelling checkers. It's easy - you just have to right-click and select the option you want, no need to think of the syntax how to write it into settings json.)

Desired solution

An option to "remember" not to lint this type of things

(to be more specific, a dialog can open to the users, what specifically they want, (to solve ambiguity) e.g.

• always only this specific 100% identical syntax,
• more generally: e.g. any type hints which use this package,
• type hints in general,
  )

Additional context

pylint already supports disabling specific linting in settings (JSON), for example:

    "python.analysis.diagnosticSeverityOverrides": {
        "reportShadowedImports": "none"
    },

This proposal - is to automatically propose the user which type of linting the concrete case is, and easily "remember" it only with gui clicks, for example, via the VSCode's "quick fix" functionality.

An advantage of this functionality (in addition to speed and convenience) - is the presentation to the users of all possible choices what kinds / combinations to ignore - ones which they might not have though of themselves but which might be more suitable to them.

[karthiknadig]

@VladimirFokow We typically don't want to disable linting via settings.json. But this could be done via pyproject.toml, or .pylintrc etc which is what pylint will itself use. This way when pylint is run via cli there won't be a difference in output.

This feels like a duplicate of: #70

[VladimirFokow]

Thanks @karthiknadig !
I'm not entirely sure that is a duplicate..

Interesting! I've never heard of neither pyproject.toml nor .pylintrc for pylint - for my use VSCode's settings (JSON) were enough. By the way, an advantage of this method could be the ability to choose who the settings influence: either your user / workspace / remote / etc. - whatever different types of settings.json VSCode offers.
Plus, if you want to export your settings to a different machine, VSCode's profiles can include settings.json.

[Pierre-Sassoulas]

Doing this there's multiple things to consider because it's possible to disable in various way:

• on the line with inline # pylint: disable=x comment or from the previous line (if the line would become too long) with # pylint: disable-next=x
• on the various englobing scopes (inside the current for loop, function, file, etc.)
• on the current selection by adding # pylint: disable=x before and # pylint: enable=x after the selection
• (maybe in a module if https://github.com/pylint-dev/pylint/projects/1 lands someday)
• on the whole project in the global configuration file
  This is not simple to do, I don't know if an API to do that directly in pylint would make sense though.

[VladimirFokow]

ah, I see the complications.
Thanks for the list of ways!

I don't mind closing this issue now

[agalazis]

I would expect # pylint: disable-next=x on top of the line as a quick fix action to always do the right thing but feel free to challenge me