] > 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 Monday 12 September à 08:25, Greg Wilson wrote:
> Hi Sylvain; thanks for your mail (and welcome back from holidays).

thanks
 
> > I'm only answering now since I'm just right back from holidays :)
> >
> > > Any thoughts on my previous message re combining PyLint and PyChecker?
> >
> > Well, yes. First, I did try to start a discussion about this on c.l.py a
> > few month ago, without any reactions, even from the main pychecker
> > author (maybe did you emailed him to nad had more luck than I add ?).

> I think perhaps Neal was also on vacation ;-)

:)

> > After that, there is two things which makes me doubt about any
> > unification, at least in a near future :
> >
> > * project's goal: pychecker is looking for bugs, while pylint is
> >   looking for bug *and* bad style code (pythonically or more generaly
> >   programaticaly related). Today pychecker is still finding more bugs
> >   than pylint, and of course I would like pylint to get them, but don't
> >   hurry to implement related checks since pychecker does them...
> > * project's implementation: they are radically different, since
> >   pychecker is working on living (ie imported) code, while pylint is
> >   working on a syntax tree representation (ie only parsed). This implies
> >   that an unification requires a rewrite of one of the two projects :(

> Not necessarily --- some of gcc's optimization passes are implemented in
> wildly different ways, but they're all bundled into the same package.

true. What I essentially mean is that I think that not actually importing
the code is a great advantage, so I would like to keep it.
 
> I asked Neal yesterday if he'd be interested in using the needs of Trac
> (http://projects.edgewall.com/trac) to guide the next round of PyChecker's
> development.  Trac now uses metaclasses to implement a component
> architecture, and our branch of it in Toronto is also using decorators.
> Handling those, and reducing the number of false or misleading reports on
> actual code, would be a good test of PyLint as well --- interested?

Sure ! Fixing false or misleading reports is my priority #1 on pylint.
Regarding new features, I'm also interested in your needs, but it falls
into the "do them when there is available time" rule...

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

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


is a reply to
in thread
has reply