Sylvain Thénault wrote, On 03/15/2010 11:56 AM:
On 14 mars 00:40, Mads Kiilerich wrote:
Pylint has a lot of options to controlling the behaviour and output.
But it is my experience that there are so many that they are very
hard to find and use correctly.
do you have some ideas about how to improve this? Do you see some
options which are in your opinion useless?
It is very hard to give constructive feedback to something as subjective
as usability - especially on the command line - but I will try ...
Pylint has functionality and options I don't think are essential, and in
my opinion it would be better not have (or show) these - neither in
code, help, documentation, nor conceptual complexity. But I did not and
will not call any of the options useless.
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. 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.
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.
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?
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?
So in _my_ opinion all the options and functionality for reports could
be removed, while the command line options for checks should polished to
match what command line users intuitively expects.
Some quick examples/ideas:
"-w" to enable more and more checks/warnings, reporting only errors by
default
"--enable" and "--disable" to enable and disable "anything" as
pylint --disable C,R,W0311 --enable C0111 foo.py
- to disable conventions and refactorings (what they should have been by
default! ;-) ) and a warning, and then enable docstring checks anyway.
or
pylint --dis C,R,W0311 --en C0111 foo.py
pylint -C -R -W0311 +C0111 foo.py
"-h W0311" to show help/description of this message
"-h W" to list warnings that can be enabled
"-v" to show more verbose messages, assuming exact and terse output by
default
I am aware that I am mixing checkers and messages and categories, but I
think/hope the concepts can be simplified.
/Mads
_______________________________________________
Python-Projects mailing list
Python-Projects@lists.logilab.org
http://lists.logilab.org/mailman/listinfo/python-projects
