Stop specifying a default linter

[DonJayamanne]

We would like to get the language server providing base error detection such that there isn't a need to specify a linter for such things.

[DonJayamanne]

We will also need to address the following:

• Communicate the switch from pylint to xyz
• Keep using pylint where users have pylint configuration files today or expect pylint to be the linter

[brettcannon]

There is also tailoring the defaults rules. It should be noted that pyflakes doesn't let you control the rules, it's all or nothing. Under flake8, though, you can set the rules, but we can't just use all of pyflakes checkers because data scientists love to use import * and pyflakes flags that as an error.

[joshburkart]

FWIW, I've found pylint to be far more comprehensive than the alternatives mentioned, though. E.g. I believe it is used internally at Google.

[gandhis1]

I firmly support Flake8. The major flaw with pylint is that it's too strict and produces too many errors.

People can still add #noqa comments to their code. When I exceed 79 chars on a line for readability reasons, I will do this.

Also, flake8 is pyflakes plus pep8 (pycodestyle). So the core linter popularity tilts even further towards pyflakes (2x downloads according to the stats posted above).

[joshburkart]

Elaborating slightly:

• I think pylint essentially subsumes flake8, but is better and more comprehensive in every way. It's slower, but not annoyingly so IMO.
  • E.g. pylint lets you disable specific messages per line or per code block rather than just everything. (# noqa is the absurdly named equivalent of the classic except Exception: antipattern.)
• I agree that the pylint defaults are slightly too strict for me, but tweaking a few settings is all I typically need. If I want to churn out a quick sloppy script then I can easily turn off various errors/classes of errors.
  • Perhaps VSCode could appropriately pop up a dialog pointing to amending ~/.pylintrc, or mentioning the # pylint: disable=... syntax...?
• Popularity is not a useless metric, but IMO pretty weak... Many confounding factors...

[DonJayamanne]

The two main reason we are looking at changing the linter is performance and less strickness.
For seasoned developers, it's an easy decision, as they are used to linters (assumption).
However someone starting out with vscode and python, they'd be very annoyed (this is what we have observed, based on user feed back via numerous channels), due to performance (show to provide results) and too strict.
From a beginners point of view pylint is just not the right linter, as theyd be scratching their heads trying to figure what's wrong with their code.

The current extension blindly uses pylint (always). The plan is to offer the choice to the user, with the default being flake8.

[patrys]

My main concern with most of the linters is that majority of the issues they report as errors are not really "errors". Terrible style will not cause a program to crash.

I think most people would be happy if pylint/flake8/whatever only reported potential crashes as errors and had the rest split between warnings and notices. If VS Code or the Python extension allowed you to select the level of reporting (just errors/errors and warnings/everything) some people could disable everything but errors (when they'd like to know that an import is missing but couldn't care less about an unused one) while others (like me) could opt to be notified about everything.

pylint is a great linter but it is terribly slow (this could be fixed by turning it into a language server though as then it could reuse some of its cache) which makes it currently painfully unusable for as-you-type linting. flake8 is fast but not nearly as useful. Half of the things it bothers you with could be fixed by an auto-formatter like yapf or black.

[brettcannon]

Do keep in mind and we do have a set of default rules which we use to tailor Pylint's behaviour in the extension when you make no personal changes. The same would be for flake8, so this isn't really an argument between which linter offer the most rules, but who has the rules we want in a default rule set to detect errors, and then which is faster.

[brettcannon]

To add to the importance of considering this (or dropping linters for a parso+LSP solution), Pylint is about to drop Python 2 support, so we would have to start having people install a specific version depending on what version of Python they are running (which we have to be careful of as the latest release doesn't support Python 3.7), switch to flake8, or stop installing linters by default.

/cc @qubitron