On 14 mars 00:40, Mads Kiilerich wrote: > Maarten ter Huurne wrote, On 03/13/2010 02:58 AM: > >On Friday 12 March 2010, Sarah Strong wrote: > >>Proposed output: > >> > >>************* Module Kontroller > >>W: 9: Bad indentation. Found 2 spaces, expected 4 > >>W: 10: Bad indentation. Found 2 spaces, expected 4 > >>W: 11: Bad indentation. Found 2 spaces, expected 4 > >>W: 12: Bad indentation. Found 2 spaces, expected 4 > >>[4 more Bad indentation messages, use --unabridged to display them all] > >In addition to avoiding discouragment of new users, it makes the more > >serious problems stand out more because they are not lost in a sea of > >repeated warnings. If pylint finds a bug on the first run it makes a good > >first impression on the user. > > I would like to add the following (obvious) observations: > > We could do more to make sure the user (by default) sees the most > important and serious errors. Showing few lines with each message as > suggested (or even just one unless -v is specified) could help. > Showing errors before (or after) warnings (and style issues) - and > making clear what is what - could also help.
the pb I see with that is that we would have to buffer all the messages, at least per module, before being able to display them. I see that as a strong disadvantage. Another solution is colorized output, understandable by most terminal. And maybe a simple gui for windows users? > We could also make it easier and more obvious how the user can > disable a warning if he don't care about it. That might be a better > solution to too verbose output. For example, in the example it could > show "W0311" by default and let the command line argument -W0311 > disable it. you mean --include-ids=yes by default? Why not. > Showing strings like W0311 also gives the novice user something that > is (or will be) googlable and thus makes it easy to find more info - > as suggested and requested. > > I agree that not showing the very verbose and > vertical-space-consuming statistics also would help. we could maybe only keep the rating by default. I would also keep the similarity and import cycles detections but there is still an argument to disable them by default: they are very very time/memory consuming. > 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? -- 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
