How to deal with Pylint's “too-many-instance-a

Question

I have just tried to lint some code with Pylint, and the last remaining error is

R0902: too-many-instance-attributes (8/7)

I understand the rationale behind limiting the number of instance attributes, but seven seems a bit low. I also realise that the linter should not have the last word. However, I would like to know what I should be doing instead of:

def __init__(self, output_file=None, output_dir=None):
    """
    Set the frobnicator up, along with default geometries
    """

    self.margin = 30

    self.pos = [0, 0]
    self.sep = [5, 5]

    self.cell = [20, 20]

    self.frobbr = library.Frobbr()

    page = self.frobbr.get_settings('page')

    self.lim = [page.get_width() - self.margin,
                page.get_height() - self.margin]

    self.filename = output_file
    self.moddir = output_dir

Should I package the geometries up into a dict, do something else to stop Pylint complaining, or just ignore it (which I don't really want to do)?

Answer 1

This is an ideological objection, but personally I tend to try to make these kind of changes as universal as possible. If 7 is not enough instances in one file, and I choose to allow it here, why not everywhere? I don't always make changes to the lint rules across the board, but I at least consider it. To that end, if you want to make an across the board change, in your .pylintrc file change max-attributes=7 in the DESIGN section.

Since I think 7 is a little low across the board, I changed:

[DESIGN]
max-attributes=7

to

max-attributes=12

Answer 2

The answer from Zero Piraeus is a good one. That said, since you provide little context to your init method, not even a real class name, it is difficult to be affirmative, but I would say filename and moddir have nothing to do aside margin, position, etc.

IO operations are often best isolated into functions rather than put into methods. Their are often many different formats and serialization options, and most of the time you do not want to mix them with your object logic (methods). It is easier to add a new IO function that takes some file, string, blob or whatever and returns the object encoded into it than it is to maintain an object that has many methods that handle many different IO operations.

Answer 3

I would disable this message altogether by adding too-many-instance-attributes to the project's pylintrc or .pylintrc file as in the example below:

[MESSAGES CONTROL]
disable=
    locally-disabled,
    locally-enabled,
    logging-format-interpolation,
    no-init,
    too-few-public-methods,
    too-many-instance-attributes,  # <-- Ensure at least this entry.
    fixme

Answer 4

A linter's job is to make you aware of potential issues with your code, and as you say in your question, it should not have the last word.

If you've considered what pylint has to say and decided that for this class, the attributes you have are appropriate (which seems reasonable to me), you can both suppress the error and indicate that you've considered the issue by adding a disabling comment to your class:

class Frobnicator:

    """All frobnication, all the time."""

    # pylint: disable=too-many-instance-attributes
    # Eight is reasonable in this case.

    def __init__(self):
        self.one = 1
        self.two = 2
        self.three = 3
        self.four = 4
        self.five = 5
        self.six = 6
        self.seven = 7
        self.eight = 8

That way, you're neither ignoring Pylint nor a slave to it; you're using it as the helpful but fallible tool it is.

By default, Pylint will produce an informational message when you locally disable a check:

 Locally disabling too-many-instance-attributes (R0902) (locally-disabled)

You can prevent that message from appearing in one of two ways:

1. Add a disable= flag when running pylint:

   $ pylint --disable=locally-disabled frob.py 
   

2. Add a directive to a pylintrc config file:

   [MESSAGES CONTROL]
   disable = locally-disabled