Greetings!
I've been playing around with a side project of using pychecker to provide early warning of typos/thinkos and questionable practices. I'm basically looking for many of the benefits that a compiler provides when it can't resolve find a variable/class/function name etc...
I've got the right mix of pychecker cmdline args such that the subset of issues is now manageable. But I'm curious if folks have any general thoughts on this subject.
What are your best practices?
Are there other similar tools out there?
Have any experiences to share or words of caution/wisdom?
Many thanks, James
James Laska wrote:
Greetings!
I've been playing around with a side project of using pychecker to provide early warning of typos/thinkos and questionable practices. I'm basically looking for many of the benefits that a compiler provides when it can't resolve find a variable/class/function name etc...
I've got the right mix of pychecker cmdline args such that the subset of issues is now manageable. But I'm curious if folks have any general thoughts on this subject.
What are your best practices?
Are there other similar tools out there?
pylint is the tool I use. pyflakes does the same sort of thing as well. I think pylint checks for the most things... which can be good or bad (you can disable groups of checks so it's not too bad.)
-Toshio
On Fri, 25 Apr 2008 13:10:18 +0000 James Laska jlaska@redhat.com wrote:
I've been playing around with a side project of using pychecker to provide early warning of typos/thinkos and questionable practices. I'm basically looking for many of the benefits that a compiler provides when it can't resolve find a variable/class/function name etc...
I've got the right mix of pychecker cmdline args such that the subset of issues is now manageable. But I'm curious if folks have any general thoughts on this subject.
What are your best practices?
Are there other similar tools out there?
Have any experiences to share or words of caution/wisdom?
Hey James,
I've been using pylint for a while and I must say it's pretty useful. It takes a while though to tune some of the tests - like * every variable has to be at least 3 chars (except for i when iterating), so often used 'id' won't pass as well as common for l in lines, for k,v in dict.iteritems() and such
* pylint complains about nonexisting properties if you override the __getattr__ method.
* in default * and ** magic is now allowed (from foo import *, def bar(*args, **kwargs), which is sometimes very useful
But it has pretty good documentation, commented config file and you can tune the checks using comments in the .py files themselves to disable a check for a file or even a block of code as simply as for example '# pylint: disable-msg=C0103' to disable warning about module variable in lowercase.
As I mentioned, you really have to take the time to configure it to your standart. As some people prefer to use CamelCase, some use_underline. After that is helps you keep the same standart throughout the whole project. And writing your own tests (plugins) is easy and fun :)
HTH, /David
David Kovalsky wrote:
On Fri, 25 Apr 2008 13:10:18 +0000
I've been using pylint for a while and I must say it's pretty useful. It takes a while though to tune some of the tests - like
- every variable has to be at least 3 chars (except for i when
iterating), so often used 'id' won't pass as well as common for l in lines, for k,v in dict.iteritems() and such
id is also a builtin:: id(...) id(object) -> integer Return the identity of an object. This is guaranteed to be unique among simultaneously existing objects. (Hint: it's the object's memory address.)
- pylint complains about nonexisting properties if you override the
__getattr__ method.
- in default * and ** magic is now allowed (from foo import *, def
bar(*args, **kwargs), which is sometimes very useful
But it has pretty good documentation, commented config file and you can tune the checks using comments in the .py files themselves to disable a check for a file or even a block of code as simply as for example '# pylint: disable-msg=C0103' to disable warning about module variable in lowercase.
It is also supposed to be able to turn tests on and off at the same level but that is broken in the current release. (Upstream says they have a fix in for the next release).
As I mentioned, you really have to take the time to configure it to your standart. As some people prefer to use CamelCase, some use_underline. After that is helps you keep the same standart throughout the whole project. And writing your own tests (plugins) is easy and fun :)
pylint --generate-rcfile is a useful option to start your customization with.
-Toshio
python-devel@lists.fedoraproject.org