Hi Anne, you can write a checker that simply stores all classes it encounters and then walks the inheritance tree to find all violations in `close`. This checker method is called after all modules specified on the commandline have been checked, but before reports are generated, so emitting warnings at this point is possible.
// Torsten 2014-11-21 18:58 GMT+01:00 Anne Mulhern <amulh...@redhat.com>: > Hi! > > I've implemented a very simple analysis of the kind described in this > enhancement > request: > https://bitbucket.org/logilab/pylint/issue/201/pointless-attribute-override-checker > . > The analysis is neither sound nor complete, but has proven useful for > removing of bits of > dead code. > > It can be made more sound by altering the algorithm so that it accumulates > data by visiting classes, > and subsequently processes that accumulated data, preferably after all > classes have been visited, > in order to determine messages to report. > > Is there some infrastructure in pylint that can accomodate an analysis > that works that way? > If there is, is there a working example that uses it? > > Thanks for any help, > > - mulhern > > _______________________________________________ > code-quality mailing list > code-quality@python.org > https://mail.python.org/mailman/listinfo/code-quality >
_______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
