[code-quality] Spurious unused variable messages
Skip Montanaro
skip.montanaro at gmail.com
Wed Jun 10 23:02:01 CEST 2015
On Wed, Jun 10, 2015 at 3:48 PM, Ian Cordasco
<graffatcolmingov at gmail.com> wrote:
> 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)
As I stated, I think that string literal formatting will be the most
common form. The token stream around that should look something like
STRING-LITERAL DOT "format"
(however that's spelled). What I'm initially interested in knowing is
what visit_* method(s) would be involved in processing such a
construct. I really don't have any idea where to begin. I think it's
going to involve astroid, but I haven't found any documentation so
far.
In particular, I'm really only interested in the case
where a variable is otherwise unused within the function, as tmpfile
was in my example. I've encountered this same issue before with
printf-style dict-based formatting, but I started thinking about it
again when I discovered that Python's standard string module has a
Formatter class which can already parse formatting strings.
> 2. Passing and splatting locals in a call to format
Not a big deal. In fact, I think you can completely ignore the
argument to format(), certainly to start with and for this particular
task.
> 3. Use of keyword arguments in the format
Not sure what you're getting at here.
> 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.
Is it possible to build an add-on for pylint which I could mess around
with? If so, and if I can learn how the basic token traversal works,
then I think I could mess around without tickling core pylint.
> 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.
Not an issue. I only mentioned 2.6 because that's when the
string.Formatter class appeared. In my own environment, 2.7 is the
standard.
More information about the code-quality
mailing list