invalid-name "propagates" to users on class properties

[mikekap]

For example, given:

# a.py
# pylint: disable=invalid-name

class AClass(object):
    badName = 'hi'

# b.py
import a

def main():
    instance = a.AClass()
    instance.badName = 'yes'

main()

The output of pylint then varies depending on which files are being linted, and the order they're linted, e.g.

$ pylint a.py
# nothing
$ pylint b.py
# nothing
$ pylint a.py b.py
# nothing
$ pylint b.py a.py
************* Module b
C:  5, 4: Invalid attribute name "badName" (invalid-name)

That's really unexpected behavior. In this case, I would expect no errors since I disabled them in the declaring module.

This doesn't appear to happen when using instance properties (i.e. init + self.badName).

[PCManticore]

This seems a duplicate of #689.

[mikekap]

It's definitely related, but I can also repro this with a single file:

def main():
    cl = Ac()
    cl.badName = 'hello'

class Ac(object):
    badName = 'hi'  # pylint: disable=invalid-name

main()

Results in

C:  3, 4: Invalid attribute name "badName" (invalid-name)

[kernc]

There's a comment here that may shed some light: https://www.logilab.org/ticket/3733 ?

[PCManticore]

I can't replicate this with the latest release, but I can replicate another issue, that is affected by this. If the first file has a disable, then this disable would be propagated inadvertently for the other files, which don't contain this disable. This is probably because we use a global messages store for all the files, which leads to a wrong view of the disable / enable pairs. In order to fix it, we'll have to check the files as well.
And probably after that, we could replicate this issue.

[PCManticore]

This would probably be fixed once we have #938 implemented (which depends partially on #618 as well). In this case, I'm moving it for that milestone.

[Pierre-Sassoulas]

I'm going to close as this was fixed at some point, or I can't reproduce anymore.