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

[PCManticore]

Hey folks, chiming in here just to mention that, although it would be sad to see pylint go as the default linter for vscode, it's an understandable decision, as I can see your pain points with the tool. Regarding the performance though, in the next major release there is some work that's going to improve the performance quite a bit (pylint-dev/astroid#497 and pylint-dev/astroid#519). There will most likely be other places from which we'd be able to squeeze some performance improvements, most likely in the inference.
Regarding Python 2 vs Python 3 support, our plan is to support two versions simultaneously. The next major release is going to be 3+ only, with a 1.9 version going in parallel until Python 2.7 goes EOL.

That being said, thanks for the honest feedback, we'll try to address these concerns as much as possible.

[brettcannon]

@PCManticore and we appreciate all the hard work put into Pylint! Chances are, though, that long-term we will move to our own solution and simply make Pylint -- and all other linters -- a supported option but not something we have users install by default (to make the setup process smoother).

[qubitron]

Looks good to me!

[brettcannon]

The prompting to install Pylint is still occurring when the language server is on.

[d3r3kk]

The prompting to install Pylint is still occurring when the language server is on.

Yes, this is expected at the current time. Until we turn Jedi off by default the current behaviour will remain, as per the request by @qubitron.

Once we resolve issue #3007 this will behave properly, but not until then.

[d3r3kk]

To resolve this issue then, one must change the setting to "pylintEnabled": false in the package.json file and then build and run the extension to verify.

[brettcannon]

I can verify that the right thing is done when pylint is installed but no settings have been provided. But I can also verify that the wrong thing is done when pylint is not installed and there are no settings provided.

@d3r3kk I thought you said you could detect when a value for a setting came from the default set versus from a user's setting somewhere?

[qubitron]

Yes, this is expected at the current time. Until we turn Jedi off by default the current behaviour will remain, as per the request by @qubitron.

Not quite -- to clarify, the request was that we don't prompt to install pylint when jediEnabled is set to false. That way:

1. Current users of the language server don't get the annoying prompt
2. When language server is on by default, the desired behavior happens automatically