] > Re: PyLint / PyChecker unification (Logilab.org)

Email Re: PyLint / PyChecker unification

from
cc
subject
Re: PyLint / PyChecker unification
date
2005/09/12 14:45
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.

> 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.  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.

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.

 * Must use source code
 * Must handle all python constructs, 
         including:  decorators, metaclasses, properties, list/gen comps
 * Must run on CPython/Jython/IronPython
 * Must be able to handle Python 2.2 - CVS versions
 * Must provide upgrade path to be integrated into Python
 * Ideally should help with Python 3000 transition (future)

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

 * Must check stdlib in less than 30 seconds with 100+ warning types
 * Must provide caching of analysis (i.e. for packages like wx)
 * Must provide plugin architecture (future)

I would be curious to hear what you would add/change/remove.

n


has reply