Advice regarding caching values as a side-effect of visiting classes
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-.... 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
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@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-... . 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
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@gmail.com> To: "Anne Mulhern" <amulhern@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 <amulhern@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-... . 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
participants (2)
-
Anne Mulhern -
Torsten Marek