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

[Sylvain Thénault]

On Thursday 30 November à 20:16, Maarten ter Huurne wrote:
> 
> 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

that's the expected usage. You don't mind if I cut and paste this into
pylint's documentation ?

> - 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

lambda expression bug should be fixed in the latest release. I'll check
the inference bug you reported asap.

> 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.

I agree, however it's not worth enough for me to implement it...

-- 
Sylvain Thénault                               LOGILAB, Paris (France)
Formations Python, Zope, Plone, Debian:  http://www.logilab.fr/formations
Développement logiciel sur mesure:       http://www.logilab.fr/services
Python et calcul scientifique:           http://www.logilab.fr/science