[Python-projects] pylint: unused local variables and their context

[Maarten ter Huurne]

Pierre Rouleau wrote on 2006-11-30 06:06:31 PM:

> This warning does annoy me a little too, however, i'd like to see 
> what other do
> to avoid the warning.
> In certain situations, the warning might just be what you need to 
remember to
> use the loop index.
> So removing the warning might not be the best solution afterall.

Like Duncan, we use a naming convention:

The code looks like this:

        for x_ in range(0, MAX):
                some_code()

        x, y, z_ = self.getCoords()

And in pylintrc we have:

dummy-variables-rgx=_|([^_]+_)|dummy

Now that I see it again, I noticed that it can be simplified to: 
([^_]*_)|dummy

> Why not write::
> 
>         x, y = self.getCoords()[:2]
>         self.checkxy(x, y)

It is not clear now what the third coordinate is for; in the case of "x, 
y, z" it can be guessed, but in some contexts it is not so obvious and 
you'd have to look up the docstrings of the method to know what info is 
being discarded.

It is not even clear that there are exactly three coordinates: maybe 
homogeneous coordinates are used and both z and w are discarded; 
discarding w may be a bug.

Also, in some cases you may want to discard an element from the middle of 
the sequence ("y" in this example).

> As far as I am concerned, I prefer to get a pylint warning for unused
> variables in tuple assignment.   I don't like leaving things hanging.

One possible solution would be to have separate warnings for:
- all variables assigned to are unused
- some variables assigned to are unused, some are used

However, I actually prefer the naming convention as a solution, since it 
makes the fact that a variable is unused explicit. Just disabling the 
messages will save you some false positives, but can introduce false 
negatives.

In our project we just accepted that we have to make some modifications in 
our code to please PyLint:
- stick to more naming conventions (unused variables ending in 
underscores, mix-in class names ending in "Mixin")
- making all abstract methods explicit (rather than just not defining them 
in the superclass)
- for messages which are useful in general, but not in a specific case: 
add "#pylint: disable-msg=X0123" comments
- for PyLint bugs: add "#pylint: disable-msg=X0123" comments
  (we trigger two bugs: one with lambda expressions I reported long ago 
and one with type inference I reported last week;
  I cannot find either of them in the bug tracker though, should I repost 
them?)
- for PyLint limitations: add "#pylint: disable-msg=X0123" comments
  (Twisted's modules create a lot of definitions dynamically so PyLint 
does not know about them)

The effort is worth it, since PyLint helps us a lot in keeping the code 
clean and finding errors early. Although most errors found by PyLint would 
also be found by the regression tests, by fixing them before committing, 
we save time. And our regression tests do not cover all code either, just 
the most complex parts.

To return to the original question: once you decide that you're going to 
write code with PyLint in mind, adopting a naming convention works better 
than disabling a separated message. I can imagine though that if you start 
using PyLint on a large existing code base, disabling a separated message 
gives you a way to reduce false positives a lot instantly, instead of 
having to refactor over the course of months.

Bye,
                Maarten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.logilab.org/pipermail/python-projects/attachments/20061130/8603bdf0/attachment.htm