[Python-Dev] Direction of PyChecker

[Neal Norwitz]

Guido van Rossum wrote:

> You'll never satisfy everyone.  Personally, I write too much code
> without docstrings, so I find the complaints about missing docstrings
> annoying.  I guess my preference would be to have the default mode ony
> complain about things that have a high probability of being *coding*
> errors -- undefined names and the like.  I forget if you're checking
> string formatting conformance yet -- that would also be useful.

I know I can't satisfy everyone.  I'm not even sure who PyChecker
should be geared to by default--newbie, intermediate, or advanced user.
A bunch of the warnings annoy me too. :-)

ISTM that it probably should be geared to newbies by default.  Since,
they are the ones that would likely benefit the most.  It's also
easier for more advanced users to change defaults.  I don't really
want to do turn on all the warnings, even though I've tended towards that.
I'm trying to figure out what would be best.

There is a single option -e/--errors that will disable all the doc string,
style, and code complexity warnings.  I think there's about 40 config
options.  So it can be configured, but would take a little work.

There is checks for format strings.  It should be pretty good now.

> Unfortunately the typical newbie doesn't have access to pychecker
> yet...

True, but that can change. :-)

> Sure!  You can add a FAQ entry yourself -- the password is "Spam".

Added 4.101.  Pretty short, let me know if you have comments.

> Python version compatibilities would be an interesting area to
> explore.

Just starting to do that.  There is a check for integer division now.
I don't really know of version incompatibilities, other than new features
such as methods on strings, list comprehension, etc.

Right now string methods are checked based on the interpreter running.
So if you run PyChecker in 1.5.2 and do ''.strip(), it should complain.
If you run PyChecker in 2.0+ and do ''.strip(), it should NOT complain.

> I would like PyChecker to use a fundamentally different way of
> scanning modules.  I believe that it currently imports the module and
> then scans the module's __dict__ for classes and functions, and
> analyses their bytecode.  That's fragile, dangerous (if you don't know
> what a module does you may not want to import it), and sometimes
> causes spurious errors, like when I have this at the global level:

Yes, this is one of the worst problems I know of.  I plan on changing this.

Neal