[code-quality] Advice regarding caching values as a side-effect of visiting classes

[Anne Mulhern]

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" <shlomme at gmail.com>
> To: "Anne Mulhern" <amulhern at redhat.com>
> Cc: "code-quality" <code-quality at 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 <amulhern at 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 at python.org
> > https://mail.python.org/mailman/listinfo/code-quality
> >
>