On Wednesday 17 March 2010, Mads Kiilerich wrote:
> It seems like pylint have different goals with different focus and
> emphasis.
>
> The man page says:
> pylint - python code static checker
>
> I think this is what I want. I would like pylint to be more like a
> "unix" command line tool, simple, "stupid", 100% reproducable and
> predictable and doing one thing well. By that criteria gcc and lint are
> nice tools, and I want something similar for python, both in content and
> output format. I don't care much about pylint's metrics for my coding
> style, but I want static semantic analysis with type inference in order
> to catch bugs as early as possible. That behavior and output is also
> usable for simple integration with editors.
In mode detail, I use pylint in this way to:
- check whether there are any obvious errors before starting manual or
automated tests, to save time
- check whether I am done refactoring, especially in the case of moving
functions or classes to a new or different module
- as a pre-commit sanity check
In this use, typically pylint is run on one or a small set of sources: those
sources that the user is currently making changes to.
> The end goal in this mode
> should be to get down to zero reported issues - either by fixing code or
> adding workarounds or disable checks. It should be simple to enable and
> disable checks, and configuration should be command line options in
> shellscripts or makefiles - not in configuration files.
I agree about zero issues being the goal, since that way any issues reported
mean there is work to be done; you don't lose time checking which issues can
be ignored and which cannot.
I disagree about the configuration: to me it is more convenient to have
pylint pick up the pylintrc that is in the same directory as the sources
instead of writing a shell script to provide those same options. As an
additional bonus, the pylintrc works on Windows too, while shellscripts and
makefiles do not (unless you require mingw or cygwin).
> pylint --help says:
> Check that a module satisfy a coding standard (and more !).
>
> This seems to have a different focus where pylint plays another role, as
> a friendly wizard working more interactively together with the user to
> move the code towards a goal (aka "better"). The output is a verbose
> "report" describing several aspects of the code. Much of the
> functionality and configurability I don't like probably makes sense here.
I have used pylint to measure code quantity and quality, using a nightly
cron-like job. It produced an HTML report that included line counts,
duplicate code and the remaining violations on all source files. It was not
in any way interactive though; could you explain that part?
> Much of the "friendly" functionality and options is disturbing noise to
> me, and optimizing for conflicting goals is obviously frustrating and
> should be avoided. Perhaps it would be better to make different tools
> for the different purposes?
I wouldn't want to have to configure two different tools. However, it would
make sense to have a "quick check" mode and a separate "full report" mode.
In the quick check mode, certain checks and reports would be disabled.
> And do people really want a command-line tool with text output in the
> second "friendly" case? Who likes to read a 100-line report with ascii
> art on the command line? Wouldn't a GUI tool or web interface for
> drilling down in the analysis and browsing the code be more suitable?
Personally, I like HTML output in this mode.
> "-w" to enable more and more checks/warnings, reporting only errors by
> default
There are a lot of warnings that I would like to see in the quick check
scenario:
- abstract methods that are not overridden: these are likely to crash the
program, so it's more efficient to fix them before testing
- unused arguments: might point to incomplete implementation
- variables shadowing something from a higher level: might be a bug
- unused imports, so I can clean them up before committing
So limiting it to only errors would not be my preference.
> "--enable" and "--disable" to enable and disable "anything" as
> pylint --disable C,R,W0311 --enable C0111 foo.py
This sounds convenient. However, it does require that each identifier
belongs only to one category, otherwise it becomes ambiguous.
> - to disable conventions and refactorings (what they should have been by
> default! ;-) ) and a warning, and then enable docstring checks anyway.
I agree that the refactor warnings should be disabled on the quick check.
The duplicate code search cannot really do its job anyway if a subset of
sources is checked.
I would want conventions enabled, since I also want zero violations there.
However, it makes sense to disable convention checking by default and allow
it to be enabled by pylintrc, since it's likely that the configuration
(regexps) will have to be tweaked to the conventions of a particular project
anyway.
> or
> pylint --dis C,R,W0311 --en C0111 foo.py
I don't think you'd be typing this line again and again; as you said it
would be in a shell script or makefile (or maybe an alias). Therefore the
characters saved by using "--dis" instead of "--disable" are not worth it,
in my opinion.
> pylint -C -R -W0311 +C0111 foo.py
This causes confusion whether "-C" is something that is disabled or an
option named "C".
> "-h W0311" to show help/description of this message
So the same as the current "--help-msg", but with a shorter name? That would
be useful, since it is likely that this will be typed directly on the
command line.
> "-h W" to list warnings that can be enabled
Do you mean the full list of messages that pylint knows, or only the ones
that are disabled?
In any case, I think you're right that there are two different ways of using
pylint, each with different goals. And that many features that are useful in
the "full report" use are complicating things in the "quick check" command
line use.
Bye,
Maarten
_______________________________________________
Python-Projects mailing list
Python-Projects@lists.logilab.org
http://lists.logilab.org/mailman/listinfo/python-projects
