On Wed, Aug 27, 2014 at 3:15 AM, François Magimel <francois.magi...@etu.enseeiht.fr> wrote: > Of course! Here is the return: > $ flake8 --version > 2.2.3 (pep8: 1.5.7, pyflakes: 0.8.1, mccabe: 0.2.1) CPython 3.4.1 on Linux > > And the code to test: > > import string > > print(string.letters)
Oh, I see the confusion. So this passes because pyflakes will compile the code but that doesn't do attribute checking (that's done at runtime by Python), so the import works just fine. Pyflakes doesn't make assumptions about the attribute (letters in this case) and to add attribute checking to every module imported would significantly increase the complexity of the project. You would have to do several things: 1. Find where the module is being imported from (I can not remember if the AST holds this information, but I strongly doubt it does) 2. Load/compile the module in question 3. Attempt to statically determine if the attribute is available which may be in fact very error-prone. The first point sounds very simple, but is in fact not as simple as it might seem. More importantly to me, I'd like to focus on the third point. While most modules do not dynamically handle attributes there are plenty which do. One prime example of this is flask. For any extension of the framework, you can use entry points so that a user can do: from flask.ext import sqlalchemy Naturally the flask.ext module does not have every extension statically defined, in fact it has some very clever machinery to provide this interface to the user that would be far too complicated to detect or handle. Adding this kind of checking would ultimately be problematic and at times flat-out wrong. If you're still up for adding this, I'd strongly encourage you to try your hand adding it to PyFlakes. I'll even give you a lot of credit if you can get it to play nicely with modules like flask.ext. _______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality