On 26 avril 12:01, Emile Anclin wrote: > Hello, > > I think we are quite near to closing the ticket #19426 "first bad > impression", but would propose the following simple enhancements : > > 1/ > "-d" option for --disable > Sylvain would have liked "-e" or "-E" for --enable to have it symmetric. > However i am not sure this is necessary since by default most checkers / > messages will stay enabled. (At least, this is how I understood the > discussion whether to disble C and R or not by default.)
I would like -e/--enable and -d/--disable, -E/--errors-only, but this introduce an incompatible change (though options refactoring is already bw incompatible). What does people embeding pylint think about that? > What is the usecase for --enable ? Is it possible to do > $ pylint --disable=C --enable=C0111 > having only C0111 enabled? yep, that's the idea. > 2/ Imho, we should add "--list-msgs" to "pylint --help" : we often want to > disable quickly a message and might not remember the id, or would like to > have a fast overview. I prefer using a run with --include-ids in such case. Maybe that should be on by default. > 3/ I also would like > -w, --warning meaning --disable=C,R > or better : > -q, --quick meaning disable=C,R and disable some more warnings > which we don't care in pre-commit like situation > (for example the list of messages under c/ listed > below) If we go that way, I would prefer adding a notion of 'mode', corresponding to a specific configuration. We akready have an 'error' mode. You propose a 'warning' mode. I've greatly simplified the command line, let's avoid recomplixie it by adding more and more options for every mode people can see. We should have -m/--mode [error|warning|...]. Ideally people can define their own modes. > Completed list of different kind of messages (proposal) what are you proposing exactly? > -----8<--------------------------------8<-------------------- > > 0/ > :W0511: Used when a warning note as FIXME or XXX is detected. > Move it to Notes / Informations let's move it to information if no other message makes the creation of a new category worth it. > (and maybe we should mention the (I) > Information category at the end of --long-help and in --lst-msgs yes [snip list] I'm not sure I want to create more categories than we already have. Some messages could actually be moved to a better suited category, but that should be done when it's really desirable, since it's a bw incompatible change that may be painful to users (update of configuration file and inline message control...) -- Sylvain Thénault LOGILAB, Paris (France) Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services CubicWeb, the semantic web framework: http://www.cubicweb.org _______________________________________________ Python-Projects mailing list [email protected] http://lists.logilab.org/mailman/listinfo/python-projects
