Email Re: PyLint / PyChecker unification

On Monday 12 September à 14:45, Neal Norwitz wrote:
> On 9/12/05, Greg Wilson <gvwilson@cs.utoronto.ca> wrote:
> > > I always believed that pychecker would need to be rewritten to use the
> > > source because there are limits to what the byte codes can provide.
> > >
> > > To address some of your other comments, they are unfortunately true.
> > > pychecker was and still is a hack.  It isn't easy enough to maintain.

to answer to a remark from another email: sure, pychecker has and is
still really useful and helpful to the python community !

> > Hi Neal,
> > 
> > Given your comments, does it make sense to push ahead with PyChecker, or
> > to fold its good ideas into PyLint?  Or something else?
> 
> I think the last actually.  I don't really know enough about pylint to
> comment on it.  I think it uses the compiler package which I have
> concerns about.  

actually pylint take information from various sources:
- raw python source file (ie stream), to extract some formating
  information lost in the ast
- ast from the compiler package, which is actually extended before being
  given to pylint to add some information and so ease analysis
- living objects to get information from extensions modules or regular 
  modules without source code available

> IIRC the compiler package doesn't work with other
> Python implementations (non-CPython).  With pychecker, I'm only trying
> to squeeze that last little bit of learning out of it until I really
> know how I want to proceed.

I agree that this kind of tool should work with other python
implementation. However I think that being based on the compiler ast to
do analysis is the right way, and so its probably better to fix it and
make it work with other python implementation than to start something
else. Notice that it seems to me that the compiler module is maintained
and up to date. At least it has been updated for python 2.4 decorator,
gen comps... I don't know any construct it can't handle (that doesn't
mean there aren't).

> Some features that pylint provides (e.g., style checking) I think are
> good to have.  If they can be integrated into one tool (and there's no
> reason why they can't), all the better.
> 
> Here's a list I worked up of what I would want from a tool.  This is a
> high level list, it does not contain details about individual
> warnings.  Note that pylint seems to do quite a bit better than
> pychecker from my understanding.

hum, actually a lot of what's listed below is already in pylint
 
>  * Must use source code

done

>  * Must handle all python constructs, 
>          including:  decorators, metaclasses, properties, list/gen comps

almost done, it may missing more properties and metaclasses
understanding

>  * Must run on CPython/Jython/IronPython

already talked about this 

>  * Must be able to handle Python 2.2 - CVS versions

pylint run with python >= 2.2

>  * Must provide upgrade path to be integrated into Python
>  * Ideally should help with Python 3000 transition (future)
 
>  * Must limit warnings by default

this is just a configuration problem

>  * Must provide error classes and filtering
>  * Must provide simple mechanism to disable spurious warnings
>        (probably through comments as the first level of defense)

done
 
>  * Must check stdlib in less than 30 seconds with 100+ warning types

herr, I can't advertise pylint on this :)

>  * Must provide caching of analysis (i.e. for packages like wx)

done

>  * Must provide plugin architecture (future)

done
 
> I would be curious to hear what you would add/change/remove.
 
I agree with all that list, after that it's only a point about what
checks should be done. And having a single tool integrating every
features of both pychecker and pylint would be a great start !

-- 
Sylvain Thénault                               LOGILAB, Paris (France).

http://www.logilab.com   http://www.logilab.fr  http://www.logilab.org