inconsistent redefinition complaint, despite 'del'

[Brian Warner]

With the new pyflakes-0.9.0, and python-2.7.10, the following program:

----
if 1:
    name = 1 # line 2
    del name
    [ name for name in [] ] # line 4

other = 1 # line 6
del other
[ other for other in [] ] # line 8
----

reports:

 /tmp/pf.py:4: list comprehension redefines 'name' from line 2

I see two problems:

* the 'del name' on line 3 should probably prevent the warning. (this sample
  is a stripped-down version of a larger file, in which I added the 'del
  name' to hush an earlier pyflakes complaint)

* the same pattern on lines 6+8 was not reported, the only difference being
  that it occurred at the top-level scope and not in a function scope.

thanks!
 -Brian

[Phil Frost (bitglue)]

Ah, yeah. So there was another change, which I can't find now, which addressed this situation (going from memory here):

foo = "foo"
if False:
  del foo
print foo

This would complain about the final 'print foo' referencing an undefined foo, but as you can see, this code runs just fine.

The underlying issue here is that pyflakes doesn't have any notion of of conditional branches. Whenever it sees an 'if', 'while', 'try/except', or similar, it just ignores it, and proceeds as if the body of the branch were not in any branch at all. Another case illustrates why:

if False:
  foo = "foo"
print foo

You'll notice pyflakes won't complain about this, even though it clearly won't work. Of course usually the conditional expression is something more complicated, and pyflakes can't actually evaluate it since that would require that it is a python interpreter. So it just makes a stupid assumption.

So, I'll have to think more about how to fix this. I think it's a situation where all cases can't be accurately covered without making some changes to the underlying assumptions that pyflakes makes. Probably it needs to build a graph of the possible code paths and consider the state of the namespace along each possible path through the graph.

I'm calling this medium priority for now since it's hard to fix without making at least one of these cases wrong, and hopefully just a minor annoyance. If that characterization seems wrong, please post some more code examples and we can look at reverting to the previous behavior.