[Python-Dev] Direction of PyChecker

[Neal Norwitz]

Jeremy Hylton wrote:

> It would be much more helpful if the default setting identified real
> bugs rather than coding style issues.  The doc string one is probably
> the most glaring.  Add a -Wall option that turns on everything to
> satisfy the pedants.

This is generally true for more advanced users, but not necessarily
for newbies.  There is the -e/--errors which eliminates many warnings.

> By way of example, I used pychecker on urllib2 yesterday.  It reported
> 78 bugs of which 3 were real.  Based on that feedback, I wouldn't use
> the tool again, but would let other people sift through the noise and
> report the bugs back to me.

I ran checker w/--errors on urllib2.  There were some warnings which
should have been excluded--I'll have to fix those.  But of the 12 warnings
produced there seems to be one real bug, which you may have caught:

	urllib2.py:1054: No global (OpenerDirectory) found

I didn't investigate the other warnings closely.

It's not always easy to know if there should really be a warning or not.
For example, an unused variable could be a real bug, even though often
it is not.  No class attribute warnings are likely bugs, but could depend 
a lot on how one codes.

I don't know if there is a good middle ground.  That's part of the
reason that you can specify a .pycheckrc file, rather than keep entering
command line arguments.  Also, there should probably be some more
general classes of command line args, like -e/--errors.  Suggestions?

Neal