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

Reply via email to