我在__init__.py文件中看到__all__。它做什么?
当前回答
__all__影响from foo import*的工作方式。
模块主体(但不在函数或类主体中)内的代码可以在from语句中使用星号(*):
from foo import *
*请求将foo模块的所有属性(以下划线开头的属性除外)绑定为导入模块中的全局变量。当foo有一个__all__属性时,该属性的值是由该类型的from语句绑定的名称列表。
如果foo是一个包,并且它的__init__.py定义了一个名为__all__的列表,那么当遇到from foo import*时,它将被视为应该导入的子模块名称列表。如果__all__未定义,foo import*的语句将导入包中定义的任何名称。这包括__init__.py定义的任何名称(以及显式加载的子模块)。
注意__all__不一定是列表。根据import语句的文档,如果已定义,__all__必须是由模块定义或导入的字符串序列。因此,您不妨使用元组来节省一些内存和CPU周期。如果模块定义了一个公共名称,请不要忘记逗号:
__all__ = ('some_name',)
另请参见为什么“import*”不好?
其他回答
它还改变了pydoc将显示的内容:
模块1.py
a = "A"
b = "B"
c = "C"
模块2.py
__all__ = ['a', 'b']
a = "A"
b = "B"
c = "C"
$pydoc模块1
Help on module module1: NAME module1 FILE module1.py DATA a = 'A' b = 'B' c = 'C'
$pydoc模块2
Help on module module2: NAME module2 FILE module2.py DATA __all__ = ['a', 'b'] a = 'A' b = 'B'
我在我的所有模块中声明__all__,并强调内部细节,这些在使用以前从未在实时解释器会话中使用过的东西时非常有用。
__all__影响from foo import*的工作方式。
模块主体(但不在函数或类主体中)内的代码可以在from语句中使用星号(*):
from foo import *
*请求将foo模块的所有属性(以下划线开头的属性除外)绑定为导入模块中的全局变量。当foo有一个__all__属性时,该属性的值是由该类型的from语句绑定的名称列表。
如果foo是一个包,并且它的__init__.py定义了一个名为__all__的列表,那么当遇到from foo import*时,它将被视为应该导入的子模块名称列表。如果__all__未定义,foo import*的语句将导入包中定义的任何名称。这包括__init__.py定义的任何名称(以及显式加载的子模块)。
注意__all__不一定是列表。根据import语句的文档,如果已定义,__all__必须是由模块定义或导入的字符串序列。因此,您不妨使用元组来节省一些内存和CPU周期。如果模块定义了一个公共名称,请不要忘记逗号:
__all__ = ('some_name',)
另请参见为什么“import*”不好?
简短的回答
__all__影响<module>import*语句。
答案很长
考虑以下示例:
foo
├── bar.py
└── __init__.py
在foo/__init__.py中:
(隐式)如果我们不定义__all__,那么from foo import*将只导入foo/__init__.py中定义的名称。(显式)如果我们定义__all__=[],那么from foo import*将不导入任何内容。(显式)如果我们定义__all__=[<name1>,…],那么from foo import*将只导入这些名称。
注意,在隐式情况下,python不会导入以_开头的名称。但是,您可以使用__all__强制导入此类名称。
您可以在此处查看Python文档。
__all__从<模块>导入中自定义**和来自<package>import*。
模块是要导入的.py文件。
包是包含__init__.py文件的目录。包通常包含模块。
模块
""" cheese.py - an example module """
__all__ = ['swiss', 'cheddar']
swiss = 4.99
cheddar = 3.99
gouda = 10.99
__all__让人类了解模块的“公共”特性。[@AaronHall]而且,pydoc认出了他们。[@Longpoke]
从模块导入*
看看swiss和cheddar是如何被引入本地命名空间的,而不是gouda:
>>> from cheese import *
>>> swiss, cheddar
(4.99, 3.99)
>>> gouda
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'gouda' is not defined
如果没有__all__,任何符号(不以下划线开头)都将可用。
不带*的进口不受__all影响__
导入模块
>>> import cheese
>>> cheese.swiss, cheese.cheddar, cheese.gouda
(4.99, 3.99, 10.99)
从模块导入名称
>>> from cheese import swiss, cheddar, gouda
>>> swiss, cheddar, gouda
(4.99, 3.99, 10.99)
将模块导入为localname
>>> import cheese as ch
>>> ch.swiss, ch.cheddar, ch.gouda
(4.99, 3.99, 10.99)
包装
在包__all__的__init__.py文件中,有一个字符串列表,其中包含公共模块或其他对象的名称。这些功能可用于通配符导入。与模块一样,__all__在从包中导入通配符时自定义*。[@MartinStettner]
以下是Python MySQL连接器__init__.py的摘录:
__all__ = [
'MySQLConnection', 'Connect', 'custom_error_exception',
# Some useful constants
'FieldType', 'FieldFlag', 'ClientFlag', 'CharacterSet', 'RefreshOption',
'HAVE_CEXT',
# Error handling
'Error', 'Warning',
...etc...
]
包的默认情况是星号,不带__all__,这很复杂,因为明显的行为代价很高:使用文件系统搜索包中的所有模块。相反,在我阅读文档时,只导入__init__.py中定义的对象:
如果未定义__all__,sound.effects import*中的语句不会将sound.eeffects包中的所有子模块导入当前命名空间;它只确保包sound.effects已经导入(可能在__init__.py中运行任何初始化代码),然后导入包中定义的任何名称。这包括__init__.py定义的任何名称(以及显式加载的子模块)。它还包括以前的import语句显式加载包的任何子模块。
最后,随处可见的堆积如山的答案、教授和漫画家,这是一个受人尊敬的传统,这是对一开始就提出问题的指责:
通配符导入。。。应该避免,因为它们会混淆读者和许多自动化工具。
[PEP 8,@ToolmakerSteve]
PEP8中定义如下:
全局变量名称(我们希望这些变量只在一个模块中使用。)这些约定与函数的约定大致相同。为通过from M import*使用而设计的模块应该使用__all__机制来防止导出全局变量,或者使用旧的惯例,在这些全局变量前加下划线(您可能希望这样做,以表明这些全局变量是“模块非公共的”)。
PEP8为Python代码提供了编码约定,该Python代码包含Python主发行版中的标准库。你越是遵循这一点,你就越接近最初的意图。
推荐文章
- 将Pandas或Numpy Nan替换为None以用于MysqlDB
- 使用pandas对同一列进行多个聚合
- 使用Python解析HTML
- django MultiValueDictKeyError错误,我如何处理它
- 如何在for循环期间修改列表条目?
- 我如何在Django中创建一个鼻涕虫?
- 没有名为'django.core.urlresolvers'的模块
- 蟒蛇导出环境文件
- Django - makemigrations -未检测到任何更改
- SQLAlchemy:引擎、连接和会话差异
- 在Python Pandas中删除多个列中的所有重复行
- 更改pandas DataFrame中的特定列名
- 将Pandas多索引转换为列
- 熊猫在每组中获得最高的n个记录
- 熊猫数据帧得到每组的第一行