from
Greg Wilson <gvwilson at cs dot utoronto dot ca>
to
Sylvain Thénault <sylvain.thenault at logilab dot fr>
cc
Neal Norwitz <nnorwitz at gmail dot com>
subject
Re: PyLint / PyChecker unification
date
Hi Sylvain; thanks for your mail (and welcome back from holidays).2005/09/12 08:25
> 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.
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?
Thanks,
Greg
