[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