On 26 avril 14:24, Emile Anclin wrote: > On Monday 26 April 2010 12:21:50 Sylvain Thénault wrote: > > I prefer using a run with --include-ids in such case. Maybe that should > > be on by default. > > > I am alright with --include-ids by default (since it's even in a pylint > alias for me ;) and I also disable --report by default). > > But if we don't do that, imho, re-run pylint with the '--include-ids' > option is not the right solution for searching a mesage id, when > you run pylint on a big project, with a undesired warning somewhere. > (As a pylint beginner I might not even know about the ids)
let's do that. > If we have simple --enable / --disable options, > we should give quick access to the list of possible messages without > having to search in --long-help for the --list-msgs option to finally > find the id of the message. Looking for a message in the (long) list doesn't seem usable. > > what are you proposing exactly? > > > I want to have a pylint "quick" as a pre-commit tool. I would be fine with > introducing a 'quick' mode. > > So what I propose, is that > $ pylint --mode quick > > would not take those messages listed under c/ because they can not be > fixed quickly and are not necessarily errors. that doesn't require a new category. > > 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...) > > For now, we have > 55 W > 46 E > 15 R > 13 C > 8 F > > so, this "might" be a hint to the fact, that the "Warning" category is > getting quite big, maybe too big. But, indeed I am not sure, I just want > a quick mode. I'm not sure that's a valid indicator. > For bw compatibiliy, would it be possible to say that "Doubtful" is > considered as a Warning sub category, and D0105 and W0105 would both be > ok? I'm really not keen on a 'doubtful' category... We should fix those that are definitly not in the right category, and keep other as they are (for instance, __future__ not first statement is an Error). -- 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 Python-Projects@lists.logilab.org http://lists.logilab.org/mailman/listinfo/python-projects
