How to deal with Pylint's "too-many-instance-attributes" message?

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
   

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

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.