Thanks! I ended up getting less ambitious with the analysis, but the definition of close() method in Misdesign checker seemed like a good working example to start with.
- mulhern ----- Original Message ----- > From: "Torsten Marek" <shlo...@gmail.com> > To: "Anne Mulhern" <amulh...@redhat.com> > Cc: "code-quality" <code-quality@python.org> > Sent: Friday, November 21, 2014 5:32:15 PM > Subject: Re: [code-quality] Advice regarding caching values as a side-effect > of visiting classes > > 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