💾 Archived View for dmerej.info › en › blog › 0079-bye-bye-pylint.gmi captured on 2024-08-31 at 12:10:18. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

2018, Aug 07 - Dimitri Merejkowsky
License: CC By 4.0

I've been using pylint[1] for almost a decade now.

1: https://www.pylint.org/

Fast-forward ten years later, and I've decided no longer use it.

Here's why.

Introduction

Let's start with an example. Consider the following, obviously incorrect code:

def foo():
    ...

if __name__ == "__main__"
    foo(1, 2, 3)

Here's what the output of pylint might look like when you run it:

$ pylint foo.py
foo.py:4: [E1121(too-many-function-args), ]
  Too many positional arguments for function call

Now let's see a few problems I've encountered while using pylint.

Pain points

Initial setup

Initial setup of pylint is always a bit painful. However, if you follow some advice[2] you can get through it.

2: Some pylint tips

False positives

A recurring issue with pylint is the amount of false positives. That is, when pylint thinks something is wrong but the code is perfectly OK.

For instance, I like using the attrs[3] library whenever I have a class that mostly contains data, like so:

3: http://www.attrs.org/en/stable/overview.html

import attr

@attr.s
class Foo:
    bar = attr.ib()
    baz = attr.ib()

Those few lines of code give me a nice human-readable `__repr__`, a complete set of comparison methods, sensible constructors (among other things), and without any boiler plate.

But when I run pylint on this file I get:

foo.py:3: [R0903(too-few-public-methods), Foo] Too few public methods (0/2)

Well, it's perfectly fine to require at least 2 public methods for every class you declare. Most of the time, when you have a class with just *one* public method it's better to just have a function instead, like this:


# What you wrote:
class Greeter
    def __init__(self, name="world"):
        self._name = name

    def greet(self):
    print("Hello", self.name)

# What you should have written instead:
def greet(name="world"):
    print("Hello" , name)

But here pylint does not know about all the nice methods added "dynamically" by `attr` and wrongly assumes our design is wrong.

Thus, if you run pylint during CI and you fail the build if any error is found, you have to insert a specially formatted comment to locally disable this warning:

import attr

# pylint: disable=too-few-public-methods
@attr.s
class Foo:
  ...

This gets old fast, especially because every time you upgrade pylint you get a new bunch of checks added. Sometimes they catch new problems in your code, but you still have to go through each and every new error to check if it's a false positive or a real issue.

But so far I had managed to overcome those pain points. So what changed?

Turning the page

Two things happened:

First, I've started using mypy[4] and a "real" type system .

4: Giving mypy a go

What I found is that mypy can catch many of the errors pylint would catch, and probably more.

Also, since it uses type annotations mypy is both faster and more precise than pylint (because it does not have to "guess" anything).

Last but not least, mypy was also designed to be used *gradually*, emitting errors only when it is *sure* there's something wrong.

Secondly, I decided to port one of my projects to Python3.7. I had to bump pylint from 1.9 to 2.1 (because older pylint versions do not support Python3.7), and I got 18 new pylint errors, which only *one* of them being actually relevant.

It was at this moment I decided to take a step back.

The rise of the linters

I realized I could use other linters (not just mypy) for almost every pylint category.

Some of the *Error* messages can also be caught by pyflakes[5] which is fast and produces very few false positive too.
The *Convention* category can also be taken care of by pycodestyle[6].
A few *Refactoring* warnings (but not all) can also be caught by mccabe[7], which measures code complexity.

So far I've been using all theses linters in *addition* to pylint, as explained in how I lint my Python[8]

5: https://pypi.org/project/pyflakes/

6: https://pycodestyle.readthedocs.io/en/latest/

7: https://pypi.org/project/mccabe/

8: How I Lint My Python

But what if I stopped using pylint altogether?

All I would lose would be some of the *Refactoring* messages, but I assumed most of them would get caught during code review. In exchange, I could get rid of all these noisy `# pylint: disable` comments. (34 of them for about 5,000 lines of code)

And that's how I stopped using pylint and removed it from my CI scripts. My apologies to pylint authors and maintainers: you did a really great job all these years, but I now believe it's time for me to move on and use new and better tools instead.

What's next

This is not the end of the story of my never-ending quest of tools to help me write better Python code. You can read the rest of the story in Hello flake8[9].

9: Hello flake8

----

Back to Index

Contact me