pylint -- should I just ignore it sometimes?
alex.kapps at web.de
Wed Oct 20 01:33:20 CEST 2010
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
> 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?
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.
More information about the Python-list