Python中__all__属性具体有什么用途?
- 内容介绍
- 文章标签
- 相关推荐
本文共计1131个文字,预计阅读时间需要5分钟。
1. Python 中模块级公开接口:通过 `__all__=[foo, bar]` 显式声明。
2.Python 没有原生的可见性控制,可见性维护依赖约定。
3.例如,双下划线开头变量被视为私有。
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():
passtest2.py
import test1
__all__ = ['func2', 'test1']
def func2():
pass
def func22():
passtest3.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 风格。
去期待陌生,去拥抱惊喜。
本文共计1131个文字,预计阅读时间需要5分钟。
1. Python 中模块级公开接口:通过 `__all__=[foo, bar]` 显式声明。
2.Python 没有原生的可见性控制,可见性维护依赖约定。
3.例如,双下划线开头变量被视为私有。
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():
passtest2.py
import test1
__all__ = ['func2', 'test1']
def func2():
pass
def func22():
passtest3.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 风格。
去期待陌生,去拥抱惊喜。

