Add support for whitelisting runtime defined globals. #27
Conversation
This is an exploratory change to allow pyflakes to ignore certain symbols that are defined at runtime, and are implicitly in scope for the given file, that pyflakes can't be made aware of in any other way (AFAICT). An environment variable is probably not the best way to do this but I wanted to get some feedback sooner than later before investing too much time into implementing this.
|
Can you post an example, a use case, where this might be needed? |
|
I needed it to keep pyflakes about complaining about the _() function used for string translation that was automatically made available in all source files for the app I was working on without needing to be imported explicitly. I can't point you to the actual code since it was proprietary but it seems the use case would be a common one given that it's easy to update globals at runtime in a way that would not be detected by pyflakes. FWIW I don't really think using an environment variable is the right approach for this, and it would be better if pyflakes would look at a .pyflakes or some other config file that would let you override these soft of things. |
|
Ah, gettext-like facility (without "import gettext" and setting "_"). I did write embedded python scripts for example for Zope (where you also are provided with certain objects magically). I think that some jython scripts might have this issue too, especially if called from embedded java. Neither environment nor config file look very good solution here as well... But it's difficult to find out how to solve it if we don't know how python finds out about those objects. If you are using some wrapper, say "webapp myscript.py" to run it with Python there should be something twisted-like "trial myscript.py" to run unit tests and maybe similarly pyflakes. You might have a very similar problem with unittests actually. Maybe you should just have a "myapppyflakes.py" script that does "import pyflakes" and extends it instead? |
|
Doing all the normal app initialization for the pyflakes run would be ideal in the sense that it will have all the right imports and whatever other state is required. But it's probably not very reasonable to do this if app startup is resource-intensive (slow) and you're running pyflakes whenever your editors saves the source file. Extending pyflakes and tinkering with the code seems like a bigger kludge to me than pyflakes providing a consistent interface for doing these kinds of overrides. Messing with pyflakes internals is likely to break during updates and is just not something I really want to get into doing as it gets pretty close to forking and maintaining your own version. I'd much rather have the option to configure pyflakes than maintain a fork. The config file option seems very reasonable to me and consistent with other tools. If pyflakes starts looking in the current directory and then goes searching up the directory tree you could even have different configurations for different projects, etc. What downside do you see for this approach? |
This is an exploratory change to allow pyflakes to ignore certain symbols
that are defined at runtime, and are implicitly in scope
for the given file, that pyflakes can't be made aware of in any other way
(AFAICT).
An environment variable is probably not the best way to do this but I wanted
to get some feedback sooner than later before investing too much time into
implementing this.