Import of __all__ from another module confuses pep257 #182

Closed
dwaynebailey opened this Issue Mar 30, 2016 · 2 comments

Projects

None yet

3 participants

@dwaynebailey

I'm doing some programmatic manipulation of __all__ but simply to create a combined all for a package.

Thus:

from .a import __all__ as all_a
from .b import __all__ as all_b

__all__ = all_a + all_b

Which to me should be fine since .a and .b are already evaluated by pep257 and have immutable __all__ based tuples.

I get the error

Could not evaluate contents of __all__. That means pep257 cannot decide which definitions are public. Variable __all__ should be present at most once in each file, in form `__all__ = ('a_public_function', 'APublicClass', ...)`. More info on __all__: http://stackoverflow.com/q/44834/. 

Interestingly if I replace __all__ in the above example as follows:

from .a import __all__ as all_a
from .b import __all__ as all_b

__all__ = ('l', 'm')

Then I get the same error. So it actually seems like pep257 can't cope with me importing __all__ from another module.

@jayvdb
Contributor
jayvdb commented Mar 30, 2016

There are two issues here.

The main one is that from .a import __all__ as all_a is using the name __all__ in a way that trips up pydocstyle. That is a new scenario I dont think we've ever considered, and definitely should be fixed.

The other aspect is that all_a is only a named variable, and pydocstyle only knows it is declared from an import statement - its contents are not loaded, so it is very unlikely that pydocstyle will ever understand __all__ = all_a + all_b . pydocstyle processes each file separately, and only uses the information contained in that file. It doesnt attempt to resolve imports to see what the imported names are.

So the first problem is solvable, but the second problem is unlikely to be solved, and you will still see Could not evaluate contents of __all__. ..., but it is effectively only a warning, and not an error.

@Nurdok
Member
Nurdok commented Mar 31, 2016

@jayvdb is right on all points, but as usual lately - it will take me some time to get to this. PRs welcome :)
@dwaynebailey - thanks for reporting this.

@Nurdok Nurdok modified the milestone: pydocstyle 1.1.0 Apr 23, 2016
@Nurdok Nurdok self-assigned this May 11, 2016
@Nurdok Nurdok added a commit to Nurdok/pydocstyle that referenced this issue May 11, 2016
@Nurdok Nurdok Fix #182 1fb9963
@Nurdok Nurdok closed this in #187 Jun 18, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment