A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2001-August/016882.html below:

[Python-Dev] Direction of PyChecker

[Python-Dev] Direction of PyCheckerNeal Norwitz neal@metaslash.com
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?

Neal



RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4