On 07/21/2009 11:08 AM, Emile Anclin wrote:
On Monday 20 July 2009 17:29:02 Sylvain Thénault wrote:
On 20 juillet 17:17, Alexandre Fayolle wrote:
* have a distinction between different kind of warnings :
- potential errors
- formatting issues (indentation, line length, name convention
...) - code cleaning (unused variables ...)
ideally, I would like to optionally disable some of them but not
the other ones, or have the warnings but not the Convention
and Refactoring issues, and so on.
Right now, filtering is by checkers. I agree filtering by severity /
message type could be nice. I generally achieve this with grep.
filtering by category is already there (see
--enable-msg-cat/--disable-msg-cat).
ok, sorry for not seeing all these nice options.
Please don't be sorry. The fact that you didn't see these options points
out that there _is_ a problem. Now you know the answer, but the next guy
as smart as you will have the same problem finding the answer. We should
see if we could improve something so that you wouldn't have had the
problem at all.
Pylint is fine software and is developed by experts - no doubt about
that. But one thing experts are generally very bad at is being
non-experts. It is hard to figure out how to make "lusers" like me
understand what is going on and use the software and all its smart
details correctly. FWIW I agree that "usability" is where pylint is
least strong.
It is very hard to contribute to improvements in this area. It is hard
to come up with a usability patch which makes major changes and where
you can argue for every detail like you can for a technical patch.
Everything in usability has some aspect of opinions and taste, and more
important than the individual details is the overall design and
consistency in the whole user experience. But I hope this constructive
criticism can be used constructively ;-)
In my opinion one important aspect of usability is "conceptual
complexity". The names of these filtering options introduce the concept
"message category". It is not obvious to me what that is, and thus I
tend to ignore these options when I browse the list of options. And
intuitively I think that when the option names are long then they must
be for some advanced and seldom used functionality.
I wanted to check the help text where the user can find this option. The
help text was so long and structured in a way which wasn't obvious to me
as user that I gave up finding it with eye-grep. I ended up piping it
through less, and fortunately I knew what to search for ... I suggest
that the default help text only contains commonly used and important
options - and especially not options for tweaking individual "checks".
I suggest that all the enable/disable options are merged to one
enable/disable option which can control anything. I think it will be
obvious from the parameter value what should be enabled/disabled.
/Mads
_______________________________________________
Python-Projects mailing list
Python-Projects@lists.logilab.org
http://lists.logilab.org/mailman/listinfo/python-projects
