[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