[IshKebab]

I can't say I've seen any but some of the code style ones are very prescriptive (function longer than N lines, short variable names etc.).

Single letter variable names are totally fine in some cases. And while very long functions may be bad, it's pretty annoying when you're adding one line to a function for the linter to say "nope. have you considered dropping everything and refactoring this?"

You can easily turn them off though. I can't remember any code based ones that are really wrong.

Maybe some are prone to false positives, e.g. warning about a default `= []` argument. But you can waive them individually.

[sevensor]

Yeah, it's the "refactoring" category where I disagree most. Too many identifiers in a function, too many lines in a function, too many branches, too many methods in a class, too few methods in a class. You can learn a lot by "fixing" these, but sometimes there's no elegant fix. Take "too many branches." Sometimes you just have to write a function with 90 lines of

    if foo(x):
        return bar(y)
    if baz(x):
        return quux(y)
    ...

Sure, there are tricks you can play. You can make the conditions hierarchical and subdivide. You can evaluate all of the conditions first and reduce the function to a lookup. You can define 45 subclasses and define a polymorphic method "frob" on x such that all you have to do is call

    x.frob(y)

I can probably think of half a dozen others. Sometimes it's a good idea, but sometimes you're just better off with a bug dumb function full of straightforward conditionals. It's worth listening to Pylint to learn all of these tricks, so that you can confidently ignore its advice when there really isn't a better way.