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

Email Re: PyLint / PyChecker unification

to
cc
subject
Re: PyLint / PyChecker unification
date
2005/09/12 08:25
Hi Sylvain; thanks for your mail (and welcome back from holidays).

> 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


is a reply to
in thread
has reply