python中的“__all__ ”作用

1、Python 可以在模块级别暴露接口：

__all__ = ["foo", "bar"]

【注意】：Python 没有原生的可见性控制，其可见性的维护是靠一套需要大家自觉遵守的”约定“，比如，双下划线开头的变量对外部不可见（私有变量）。

① __all__  是针对模块公开接口的一种约定，比起双下划线的方式（私有变量或者私有函数）， __all__ 以提供了”白名单“的形式暴露接口。

②一些不以下划线开头的变量（比如从其他地方 import  到当前模块的成员）可以同样被排除出去。

③如果定义了__all__，其他文件中使用 from xxx import * 导入该文件（可以是模块或者包）时，只会导入 __all__ 列出的成员，可以其他成员都被排除在外。

如，test1.py,test2.py,test3.py三个文件：

test1.py

#__all__ = ['func']
def func():
pass

test2.py

import test1

__all__ = ['func2', 'test1']
def func2():
pass

def func22():
pass

test3.py

from test2 import *

func2() 
test1.func() 
func22()

程序运行结果：

func2() #能正常引用
test1.func() #能正常引用
func22() #不能正常引用

2、控制 from xxx import * 的行为

python3种不提倡用  from xxx import * 这种写法。如果一个模块 xxx 没有定义  __all__ ，执行 from spam import *  时会将 xxx 中所有非下划线开头的成员（包括该模块import的其他模块成员）都会导入当前命名空间，这样就可能弄脏当前的命名空间。

显式声明了 __all__ ， import *  就只会导入  __all__  列出的成员，如果  __all__  定义有误，还会明确地抛出异常，方便检查错误。

3、为 lint 等代码检查工具提供辅助

编写一个库的时候，经常会在  __init__.py  中暴露整个包的 API，而这些 API 的实现可能是在包中其他模块中定义的。如果我们仅仅这样写：

from foo.bar import Spam, Egg

一些代码检查工具，如 pyflakes 就会报错，认为 Spam 和 Egg 是 import 了又没被使用的变量。当然一个可行的方法是把这个警告压掉：

from foo.bar import Spam, Egg  # noqa

但是更好的方法是显式定义 __all__，这样代码检查工具会理解这层意思，就不再报 unused variables 的警告：

from foo.bar import Spam, Egg

　　__all__ = ["Spam", "Egg"]

需要注意的是大部分情况下 __all__ 都是一个 list，而不是 tuple 或者其他序列类型。如果写了其他类型的 __all__，如无意外 pyflakes 等 lint 工具会无法识别出。

4、定义 all 需要注意的地方

• 如上所述， __all__  应该是列表数据类型。
• 不应该动态生成  __all__ ，比如使用列表解析式。 __all__  的作用就是定义公开接口，如果不以字面量的形式显式写出来，就失去意义了。
• 即使有了 __all__  也不应该在非临时代码中使用 from xxx import * 语法，或者用元编程手段模拟 Ruby 的自动 import。Python 不像 Ruby，没有 Module 这种成员，模块就是命名空间隔离的执行者。如果打破了这一层，而且引入诸多动态因素，生产环境跑的代码就充满了不确定性，调试也会非常困难。
• 按照 PEP8 建议的风格，__all__ 应该写在所有 import 语句下面，和函数、常量等模块成员定义的上面。

如果一个模块需要暴露的接口改动频繁，__all__ 可以这样定义：

__all__ = [
    "foo",
    "bar",
    "egg",
]

这样修改一个暴露的接口只需要修改一行，方便版本控制的时候看 diff。最后多出的逗号在 Python 中是允许的，符合 PEP8 风格。