Hi, > > 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?
While I wasn't the target of this question, I wouldn't mind weighing in on this, as it's something I was just speaking with one of my peers about. We were looking at pylint's man page, and we got on to the topic of how overwhelming the number of command line options is. My thought was that some options that are currently command line options should only be adjustable in the rc file. Obviously, there are some options that you might reasonably want to tweak across different runs of pylint without having to edit the rc file (--output-format, or --profile for example). There are some things that simply *must* be command line arguments, like --rc-file, or --help, or --generate-man. But aside from those, there are a lot of options that you would probably want to just set and forget. For example, I can't imagine anyone wanting to torture themselves with typing in a bunch of regular-expressions that their variable names should match for every time they run pylint. A quick, off-the-cuff survey of what I think could be trimmed from the command line options (organized by the headings in the man page): - --cache-size - --comment - --enable-report, --disable-report - --evaluation - everything in design (max locals, max args, max returns, etc.) - everything in format (max lines, max line length, indent string) - everything in similarities - everything in typecheck - everything in variables - all the regexes in basic I may be wrong - maybe this doesn't accord with how other people use pylint. For me though, all of the above would be things I would modify in the rc file, and not want to futz around on the command line with. If you wanted to maintain backwards-compatibility, I suppose it wouldn't hurt to leave all the above command-line options in, while removing any mention of them in the --help text and the man page (perhaps a full listing of them could go in a file tucked away in the /doc directory for those interested). In any case, I strongly concur with Mads on the point you quoted. My team found the number of command-line options to be one of the most intimidating things about Pylint when we first started using it. The help menu was so long that we just threw up our arms in surrender, since we had no way of separating the truly useful options from the more obscure, fine-grained controls. Thus, it took us longer than it should have to discover the options that we now use frequently like -r, -f, and -e. -- Colin Morris Team Tahiti University of Toronto On Mon, Mar 15, 2010 at 6:56 AM, Sylvain Thénault < [email protected]> wrote: > > 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 > [email protected] > http://lists.logilab.org/mailman/listinfo/python-projects
_______________________________________________ Python-Projects mailing list [email protected] http://lists.logilab.org/mailman/listinfo/python-projects
