[Python-Dev] Direction of PyChecker
Fri, 10 Aug 2001 11:38:48 -0400
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?