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.