Pros, cons, and dangers of PyLint

Get the most out of PyLint.

Knock on the blackboard: PyLint is actually good!

"PyLint can save your life" is an exaggeration, but not as much as you might think. PyLint can save you from very hard to find and complex defects. At worst, it only saves test running time. At its best, it helps you avoid complex errors in production.

Advantages

I'm embarrassed to say how common this is. Test names are always so weird: no one cares about the name, and often a natural name can't be found. For example, the following code:

def test_add_small():# Math, am I right?assert 1 + 1 == 3def test_add_large():assert 5 + 6 == 11def test_add_small():assert 1 + 10 == 11

The test takes effect:

collected 2 items test.py .. 2 passed

But the problem is: if you override the name of a test, the testing framework will happily skip the test!

In reality, these files may have hundreds of lines, and the person adding a new test may not know all the names. Everything looks fine until one takes a closer look at the test output.

The worst part is, The addition of covered tests, The damage caused by covered tests, and the chain reaction problemmay take several It may take days, months or even years to discover.

PyLint will find it

Like a good friend, PyLint can help you.

test.py:8:0: E0102: function already defined line 1 (function-redefined)

Cons

Just like the 90s sitcom, the more you learn about PyLint, the more problems you get. Here's regular code for a stock modeling program:

"""Inventory abstractions"""import attrs@attrs.defineclass Laptop:"""A laptop"""ident: strcpu: str

But PyLint seems to have its own opinions (probably formed in the 90s) and isn't afraid to state them as fact:

$ pylint laptop.py | sed -n '/^laptop/s/[^ ]*: //p'R0903: Too few public methods (0/2) (too-few-public-methods)

DANGER

Ever thought about adding your own unsubstantiated opinion to a tool used by millions of people? PyLint has 12 million downloads per month.

"If you're too picky, people will uncheck" — This is PyLint GitHub issue 6987, raised on July 3, 2022

For a possible addition There are a lot of false positives for the test, and its attitude is... "eh".

Make it work for you

PyLint is great, but you need to be careful with it. To make PyLint work for you, here are the three things I recommend:

1. Fixed version

Fix the version of PyLint you use to avoid any surprises!

Define in your ​​.toml​​ file:

[project.optional-dependencies]pylint = ["pylint"]

Define in code:

from unittest import mock

This corresponds to the following code:

# noxfile.py...@nox.session(python=VERSIONS[-1])def refresh_deps(session):"""Refresh the requirements-*.txt files"""session.install("pip-tools")for deps in [..., "pylint"]:session.run("pip-compile","--extra",deps,"pyproject.toml","--output-file",f"requirements-{deps}.txt",)

2. Default prohibition

Disable all checks, and then enable those that you think have a high false positive rate. (Not just the false negative/false positive ratio!)

# noxfile.py...@nox.session(python="3.10")def lint(session):files = ["src/", "noxfile.py"]session.install("-r", "requirements-pylint.txt")session.install("-e", ".")session.run("pylint","--disable=all",*(f"--enable={checker}" for checker in checkers)"src",)

3. Checkers

The following are the checkers I like. Improve project consistency and avoid obvious mistakes.

checkers = ["missing-class-docstring","missing-function-docstring","missing-module-docstring","function-redefined",]

Using PyLint

You can just use PyLint for the good parts. Run it in CI for consistency and use common checkers.

Discard the bad part: disabling the checker by default.

Avoid dangerous parts: Fixed version to avoid surprises.

The above is the detailed content of Pros, cons, and dangers of PyLint. For more information, please follow other related articles on the PHP Chinese website!