Email Re: PyLint / PyChecker unification

On 9/12/05, Sylvain Thénault <sylvain.thenault@logilab.fr> wrote:
> On Monday 12 September à 08:25, Greg Wilson wrote:
> > >
> > > 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 ;-)
> 
> :)

I was on vacation for about 3 months.  It sure was nice. :-)  I
disabled almost all of my list accounts and rarely touched a computer.

> > > 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 agree that not importing code is an advantage.  I think in the long
term it would
be good to be able to do both.  There probably shouldn't be a real
need to import python code, since we can synthesize that information
if we choose (by acting as an interpreter).  I'm not sure if we want
to do this due to security concerns.  If it was done, it should
probably be restricted.

Importing extension modules could have some real benefit.  I also had
a patch to the python interpeter which would allow extension modules
to provide more information about the number of arguments that were
required/allowed.  This information would also help do a better job
determining if calling functions had the correct parameters.

OTOH, some extension modules crash the interpreter (currently I know
matplotlib and wx do).  So the problem classes have to be blacklisted
to prevent a segfault.

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

This has been my problem in the past.  Plus I wasn't very motivated
for various reasons.
A lot of that has changed--I am currently more motivated and should
have more time.

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. 
pychecker was a useful experiment (IMO) to see how far we can go by
using static analysis on python code.  I've learned a lot and have a
better idea what can be done to find more problems.

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. 
Though some things are easier than others.  There is almost no
documentation which also makes it difficult for new comers.

It seems we are probably more similar in thought, it's just that the
pychecker implementation doesn't reflect my thinking.

My biggest concern is actually with using the compiler package in the
python library.  It doesn't parse all code and can be quite slow from
previous experiments (perhaps the situation is different now, I don't
really know).  In general, compiler isn't maintained well enough.  I
was hoping that the AST branch in python would bear more fruit, but
that isn't really making progress either.  So I have some outstanding
issues in my own mind about how to move forward.

n