from
Sylvain Thénault <sylvain.thenault at logilab dot fr>
to
Greg Wilson <gvwilson at cs dot utoronto dot ca>
cc
Sylvain Thénault <sylvain.thenault at logilab dot fr>
subject
Re: PyLint / PyChecker unification
date
On Monday 12 September à 08:25, Greg Wilson wrote:2005/09/12 14:45
> 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
