[Python-Dev] Direction of PyChecker (original) (raw)

Neal Norwitz neal@metaslash.com
Fri, 10 Aug 2001 15:29:45 -0400

Jeremy Hylton wrote:

>>>>> "NN" == Neal Norwitz <neal@metaslash.com> writes: NN> 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. NN> This is generally true for more advanced users, but not NN> necessarily for newbies. There is the -e/--errors which NN> eliminates many warnings. Do you mean that it is better for newbies if the tool emits many warnings though they may be spurious? I would think the reverse: A newbie is going to have a lot more trouble deciding that the bug reported by PyChecker is, in fact, not a bug at all. They haven't developed the expertise or confidence to disagree with the tool.

You've got a very good point here. I'm not conviced, but I'm very close. So keep working. :-)

I agree that the doc strings should not be warned about by default. That will be changed. As I said before, I think that the modules/classes in the standard library should have them. And docstrings are definitely doc, not code.

In part, it's a question of first impressions. If the user sees a very high number of false positives the first time they see the tool, they're not going to see it as very useful.

I agree.

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

NN> I ran checker w/--errors on urllib2. There were some warnings NN> which should have been excluded--I'll have to fix those. But of NN> the 12 warnings produced there seems to be one real bug, which NN> you may have caught: I don't know what I'm doing differently today, but I don't see any of the warnings about classes without doc strings and the like. Could something have changed very recently? Was I imagining the output I saw the other day?

I didn't change it yet! :-) The default (currently) is to warn about missing docstrings for modules and classes, not functions or methods. This will change shortly (missing docstrings will not generate a warning by default).

I also added some config options, so now the # of warnings on urllib2 dropped when using --errors.

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

There seem to be a lot of spurious complaints related to class hierarchies. I see a bunch of complaints that a sublcass doesn't have an init() -- but subclasses don't need to have an init and often shouldn't.

Lacking an init() should be off by default.

There are also complaints about attribute used by an abstract base class but only defined in the subclass.

This is true. While python doesn't require setting, I think this feature can be dangerous. It seems better to init the attr to None.

In urllib2, there are 6 warnings about 2 different attributes. I can provide a config option to turn that off too.

Neal