On Thursday 16 July 2009 16:28:21 Marius Gedminas wrote:
> On Thu, Jul 16, 2009 at 09:25:26AM +0200, 
[email protected] wrote:
> > > -----Original Message-----
> > > From: [email protected] [mailto:python-
> > > [email protected]] On Behalf Of Marius Gedminas
> > > Sent: jeudi 16 juillet 2009 0:11
> > > To: [email protected]
> > > Subject: [Python-projects] A first impression of pylint
> >
> > Thanks for your feedback.

Thanks for your remarks. I agree with a lot of them and already thought 
about some of it.

> > Two quick notes, before others give you a more complete answer :
> >
> > * using 'pylint -e' will only report Errors and therefore
> > considerably speed up things
>
> I neglected to mention that I was using pylint -e.

Hm, that's strange, you shouldn't have the "fascist-looking warnings" in 
that case...
>
> > * disabling the similarities checker can significantly improve speed,
> > especially when running on a large code base. I'm responsible for
> > this part of the code, and the complexity (from the top of my head)
> > is O(n**2) (n being the number of lines in the code base). We should
> > probably disable it automatically (unless the user explicitely asks
> > for it) when the number of lines exceeds some threshold.
>
> Sounds like a good idea.

I added a ticket on the question of pylint's user interface with some
of my remarks and some those mentionned here:

https://www.logilab.net/elo/ticket/9774

Some remarks for simplifying/improving pylint's user interface: imho, 
pylint should 

* have a tool to generate a sample pylintrc file with all checks enabled 
by default
* have a much shorter message on the '-h, --help' options, around 20 / 30 
lines (the biggest part should be in the manpage) 
* disable similarities checking by default for code of a given size
* have an option to list all checker-ids (instead of having to search the 
documentation)
* 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.

maybe it would even be better not to produce a report by default
(the import things are the messages, not the stats).

-- 

Emile Anclin <[email protected]>
http://www.logilab.fr/   http://www.logilab.org/ 
Informatique scientifique & et gestion de connaissances
_______________________________________________
Python-Projects mailing list
[email protected]
http://lists.logilab.org/mailman/listinfo/python-projects

Reply via email to