pylint -- should I just ignore it sometimes?

[Alexander Kapps]

On 20.10.2010 00:36, Seebs wrote:
> On 2010-10-19, Martin P. Hellwig<martin.hellwig at dcuktec.org>  wrote:
>> Well, as with all styles IMHO, if there is a _good_ reason to break it,
>> then by all means do, but you might want to consider putting in a
>> comment why you did that and add the #pylint: disable-msg=<message_id>
>> on that line. If that is overkill, why not just comply to the standard
>> and avoid all the fuzz?
>
> Well, part of what I'm trying to understand is why the standard in question
> says what it says.  I'm pretty much mystified by a claim that something with
> seven instance attributes is "too complicated".  For instance, I've got a
> class which represents (approximately) a C function, for use in writing
> various wrappers related to it.  It has name, return type, args, default
> values, a list of arguments which need various modifications, a default
> return value, and so on... And it ends up with, apparently, 10 instance
> attributes.
>
> I can't tell whether there's actually a general consensus that classes
> should never be nearly that complicated, or whether pylint is being a little
> dogmatic here -- I haven't seen enough other Python to be sure.  I'm
> used to having objects with anywhere from two or three to a dozen or more
> attributes, depending on what kind of thing they model.  It seems like a
> very odd measure of complexity; is it really that unusual for objects to have
> more than seven meaningful attributes?
>
> -s

The general idea is, that modules, classes, methods, and functions 
should be small so they are better reusable, manageable and 
understandable. If you have a huge class or function with many 
attributes or local variables, it's often a sign, that your 
class/function does to much and you better refactor this into 
smaller pieces. There isn't and there can't be a general consensus 
about /how/ small some part should be.

If pylint complains about too many variables or such, take it as a 
hint to rethink your design. If you say, my design is good, then 
feel free to ignore the warning.

If your classes wrap some existing datastructure and pyling 
complains, take it as a hint (just a hint, not more) that maybe your 
underlying datastructure is to complex.

But there are no general rules. In the end you (the programmer) has 
to decide how the code or the data is structured, pylint can only 
give you hints, that there *may* be a problem.

I don't know why "the standard" (what standard?) says what it says, 
but I guess, it's the result of long time experiences and analysis 
of existing code. Trust them, unless you are sure to know better.