[Python-Dev] Direction of PyChecker

[Neal Norwitz]

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