__slots__

Alex Martelli aleaxit at yahoo.com
Sat Mar 25 18:45:34 EST 2006


John J. Lee <jjl at pobox.com> wrote:

> aleaxit at yahoo.com (Alex Martelli) writes:
> [...]
> > you should be using pychecker or pylint
> [...]
> 
> I'm curious, as somebody who doesn't regularly use these tools: How do
> they fit into your workflow?  Do you run them every few hours, every
> day, every time you run functional tests, every release, every so
> often, on gut feeling about when it's likely to catch problems...?

I use them before mailing code off for review (which in our workflow is
mandatory before the code is submitted into the codebase) -- not quite
as often as unittests, which I run with just about every keystroke in my
editor;-). I'd rather have such a tool run automatically, as a presubmit
check, but that depends on convincing every colleague that it's worth it
(probably hopeless for pychecker as long as it needs to i


> How do you cope with spurious warnings?  Does it involve tweaking code
> to quell warnings?  Keeping suppression lists?  Maintaining special
> invocations of pychecker / pylint per-project?  Do they cope well with
> other people's code who do not use these tools?

If said "other people's code", for example, does pointless (but
hopefully innocuous, otherwise unittests would have caught that;-)
things such as importing modules it never uses, the warning tools
complain. I do not consider such complaints "spurious", and prefer to
fix those things (sending the brief codereview to the original author
with advice to start using the checking tools -- it usually works;-).

Very occasionally, there _are_ warnings which are indeed spurious: the
typical example is a function which, to comply with a certain API, MUST
take three arguments named exactly x, y, and z (no more, no less, not
with any different names) but only needs x; in such cases, you do need
to add, e.g.,
    __pychecker__ = 'unusednames=y,z'
I pay the price gladly, since this will also serve to reassure human
readers that my code's anomalous behavior (accepting arguments y and z
but ignoring them) is by design, and not an accident or mistake.  I do
just about the same thing with the lint variant we use for C++, btw.


Alex



More information about the Python-list mailing list