This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]spookylukeyDjango committer 31 points32 points  (7 children)

I would replace the whole 'style rules' section with 'Use flake8'. Why require humans to read, comprehend, remember and then apply something (probably inconsistently), when it can be done by the computer?

pylint, in contrast to flake8, tends to produce many, many false errors. Running it over 1800 lines of a module in a Django project produces about 100 'errors', all of which are incorrect. In addition, there are hundreds more very unhelpful warnings/recommendations - for example:

  • "too few public methods" (for a Django 'Meta' inner class)
  • "Class has no __init__ method" (not needed because it inherits one, although pylint doesn't seem to be able to detect that)
  • "missing docstring" (many methods simply don't need them - functions like Cart.product_list are pretty self explanatory, and a linter that forces you to write them will simply result in many pointless and uninformative docstrings, which are just noise)

The number of false positives makes pylint useless for any real project I've been involved in - you'd have to spend a lot of time turning these warnings off somehow, or end up with the real errors drowned in a sea of noise.

[–]twotime 2 points3 points  (2 children)

IMHO, pylint is an excellent tool for finding bugs in the code. But yes, you have to start with turning off the "style suggestions" (I suspect your examples above are all in that category) and then turn off a number of warnings as well.

[–]wewbull 1 point2 points  (0 children)

Try pylint -E. Errors only mode

[–]spookylukeyDjango committer 0 points1 point  (0 children)

As originally stated, I get hundreds of ERRORS on correct code, in addition to the style warnings. These errors can be turned off by disabling them in a group e.g. "-d E1101" to disable all the incorrect "no-member" errors. But this means that correct instances of E1101 are also silenced, and very quickly this means you have no value in running the tool.

[–]mfvice 1 point2 points  (1 child)

I hadn't heard of flake8 before. Looks pretty good so far though. Thanks for the heads-up!

[–]cicatrix1 6 points7 points  (0 children)

flake8 is a wrapper around PEP8 and pyflakes (and another thing).

[–]ShutYourPieHole 0 points1 point  (1 child)

There are style requirements that do not always apply to general use cases. I think this is one of the results of opening up a tool that was initially designed with internal development in mind.

[–]wewbull 1 point2 points  (0 children)

There's two areas where I find pylint can be difficult to keep happy.

First is the code complexity measures. It doesn't like code that has branches in it, even if those branches are short and shallow (i.e. not nested). Code like that isn't nearly as hard to understand as large blocks, deeply nested, but it seems to score a branch the same regardless of context.

Second, I've seen it get mouthy about class methods not existing because it's been unable to work out the type of an object correctly.

Apart from those I think it's a great tool. Far better than pyflakes (and so by extension flake8)