[code-quality] Spurious unused variable messages

Ian Cordasco graffatcolmingov at gmail.com
Wed Jun 10 22:48:55 CEST 2015


On Wed, Jun 10, 2015 at 2:26 PM, Skip Montanaro
<skip.montanaro at gmail.com> wrote:
> Code like this:
>
>     import os
>     import tempfile
>
>     def func():
>         (fd, tmpfile) = tempfile.mkstemp(dir="/tmp")
>         os.close(fd)
>         print "{tmpfile}".format(**locals())
>
> generates an unused variable warning for tmpfile, even though it's
> referenced in the string in the print statement. The string module has
> a Formatter class (since 2.6, apparently) which knows how to tear such
> format strings apart:
>
>     >>> for elt in fmt.parse("{} {tmpfile} {1} {0:.3f}"):
>     ...   print elt
>     ...
>     ('', '', '', None)
>     (' ', 'tmpfile', '', None)
>     (' ', '1', '', None)
>     (' ', '0', '.3f', None)
>
> I'm only now getting comfortable with the new string formatting stuff,
> but it seems to me that the most common use case will be to call the
> format method of a string literal (so this sort of usage should be
> fairly easy to detect).  I don't think it should be terribly difficult
> to intersect the names coming out of Formatter.parse with the
> otherwise unused local variables, but I am completely unfamiliar with
> pylint's node traversal handlers (all the visit_* methods in
> variables.py).  Can someone point me to some documentation for how
> this works, and what visit_* methods I can define?
>
> Thanks,
>
> Skip Montanaro

So, I'm not sure how much pylint will read into that statement. It has
to recognize a few things:

1. String formatting (admittedly not that hard when the string wasn't
built up, as in this example)
2. Passing and splatting locals in a call to format
3. Use of keyword arguments in the format

Keep in mind, I'm not saying this shouldn't be fixed (or that it
can't) just that there's a lot in play in this example beyond simply
parsing the new string format.

Apropos of nothing, the empty {} only works on 2.7 and beyond. 2.6
didn't support that. If you're going for 2.6 compat, you'll want to
avoid that.


More information about the code-quality mailing list