Import of __all__ from another module confuses pep257

[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]

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]

@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.