warn on locals()

[John Vandenberg]

When locals() is encountered, unused variable detection is repressed.
Use of locals() should cause a warning to occur, indicating that unused variable can not be detected.

[Ian Cordasco (icordasc)]

I believe we used to do this but we stopped because a great deal of people complained.

[Phil Frost (bitglue)]

I suppose another way to handle it would be to count any usage of locals() as having used all local variables. No warning.

It would make the decision easier to have references to real code in the wild for which this is a problem.

[John Vandenberg (jayvdb)]

> count any usage of locals() as having used all local variables. No warning.

I believe this is the current behaviour...?

It was introduced in http://bazaar.launchpad.net/~pyflakes-dev/pyflakes/master/revision/64 , Jan 2013, by Domen Kožar

That was a very necessary improvement, as it removed false positives.

However the use of locals() can be seen as a source of problems, as it prevents most tools from performing simple checks of code quality. That should be a separate warning IMO. Ideally in pyflakes as the analysis is already being done. If not, someone else needs to do it.

The python-hacking rule H501 covers some of this territory.
https://github.com/openstack-dev/hacking/blob/master/hacking/checks/dictlist.py

[Ian Cordasco (icordasc)]

As a core reviewer on hacking, that rule exists because the larger OpenStack community decided they wanted to enforce it. Hacking may be used by other projects, but is fundamentally a tool for enforcing OpenStack's community style guide for Python code.

[Phil Frost (bitglue)]

Well, pyflakes as a matter of principle does not opine on matters of style. There are certainly uses of locals() which are valid, useful, and not horrible to read, like:

    "%(local)s %(variable)s %(names)s" % locals()

The closest precedent for complaining about locals() might be that pyflakes complains about "import *", but I would say that's not quite the same. locals() has no side effects and depends only on the local scope. "import *" has side effects that are not only implicit, but dependent on other files.

[asmeurer (asmeurer)]

It's also not uncommon to pass locals() to eval() or exec() (granted, those both break pyflakes anyway, but I don't think pyflakes should be bugging people just because they use eval).

[John Vandenberg (jayvdb)]

> The closest precedent for complaining about locals() might be that
> pyflakes complains about "import *"

This, and the pep257 warning regarding `__all__` being mutable, was the reason I raised this issue.
The pyflakes rule regarding unused variable is currently being silently repressed when locals() is used.

Both mean that static analysis in not possible by the tool with its current design/limitations.

I can appreciate the scope is different, module vs function, but then pyflakes is making a decision on the importance of a rule based on the scope. When a module is mostly a large main(), the scope is irrelevant.