__init__.py：它是一个在包目录中找到的Python文件，在导入包或包中的模块时调用。您可以使用它来执行包初始化代码，即每当导入包时，在执行此文件夹中的其他模块之前，首先执行python语句。它类似于c或Java程序的主函数，但它存在于Python包模块（文件夹）中，而不是核心Python文件中。它还可以访问__init__.py文件中定义的全局变量，就像将模块导入Python文件一样。

例如。我在一个名为pymodlib的文件夹中有一个__init__.py文件，该文件包含以下语句：

print(f'Invoking __init__.py for {__name__}')
pystructures = ['for_loop', 'while__loop', 'ifCondition']

当我在解决方案模块、笔记本或python控制台中导入此包pymodlib时：这两条语句在导入时执行。因此，在日志或控制台中，您将看到以下输出：

>>> import pymodlib
Invoking __init__.py for pymodlib

在python控制台的下一条语句中：我可以访问全局变量：

>> pymodlib.pystructures

它给出以下输出：

['for_loop', 'while__loop', 'ifCondition']

现在，从Python3.3开始，可以选择使用该文件来使文件夹成为Python模块。因此，您可以跳过将其包含在python模块文件夹中。

如果您使用的是Python 2，并且希望加载文件的同级文件，那么只需将文件的父文件夹添加到会话的系统路径中即可。它的行为与当前文件是init文件的情况大致相同。

import os
import sys
dir_path = os.path.dirname(__file__)
sys.path.insert(0, dir_path)

之后，相对于文件目录的常规导入将正常工作。例如。

import cheese
from vehicle_parts import *
# etc.

一般来说，您希望使用一个合适的init.py文件，但在处理遗留代码时，您可能会遇到f.ex.一个硬编码的库来加载特定文件，而不是其他文件。对于这些情况，这是一种选择。

除了将目录标记为Python包并定义__all__之外，__init__.py还允许您在包级别定义任何变量。如果包以类似API的方式定义了将频繁导入的内容，那么这样做通常很方便。这种模式促进了对Pythonic“扁平优于嵌套”哲学的坚持。

一个例子

这里是我的一个项目中的一个示例，其中我经常导入一个名为Session的sessionmaker来与我的数据库交互。我编写了一个包含几个模块的“数据库”包：

database/
    __init__.py
    schema.py
    insertions.py
    queries.py

我的__init__.py包含以下代码：

import os

from sqlalchemy.orm import sessionmaker
from sqlalchemy import create_engine

engine = create_engine(os.environ['DATABASE_URL'])
Session = sessionmaker(bind=engine)

因为我在这里定义了会话，所以可以使用下面的语法启动新会话。该代码将与从“数据库”包目录内部或外部执行的代码相同。

from database import Session
session = Session()

当然，这只是一个小小的方便——另一种选择是在数据库包中的一个新文件（如“create_Session.py”）中定义Session，然后使用以下命令启动新会话：

from database.create_session import Session
session = Session()

进一步阅读

这里有一个非常有趣的reddit线程，介绍了__init__.py的适当用法：

http://www.reddit.com/r/Python/comments/1bbbwk/whats_your_opinion_on_what_to_include_in_init_py/

大多数人认为__init__.py文件应该非常薄，以避免违反“显式优于隐式”的原则。

__init__.py允许的一件事是将模块转换为包，而不破坏API或创建无关的嵌套命名空间或私有模块*。这有助于我扩展命名空间。

如果我有一个包含

def foo():
    ...

然后用户将使用

from util import foo

如果我想为数据库交互添加实用程序函数，并且希望它们在util下有自己的命名空间，那么我需要一个新目录**，并且为了保持API兼容性（这样从util import foo仍然可以工作），我将其称为util/。我可以像这样将util.py移动到util/中，

util/
  __init__.py
  util.py
  db.py

在util/__init__.py中

from util import *

但这是多余的。我们可以将util.py内容放在__init__.py中，而不是使用util/util.py文件，用户现在可以

from util import foo
from util.db import check_schema

我认为这很好地突出了util包的__init__.py的作用方式与util模块类似

*这在其他答案中有所暗示，但我想在这里强调一下**没有采用进口体操。请注意，创建与文件同名的新包是行不通的，请参见

尽管Python在没有__init__.py文件的情况下工作，但仍应包含一个。

它指定目录应被视为一个包，因此包含它（即使它是空的）。

还有一种情况是，您可能实际使用__init__.py文件：

假设您具有以下文件结构：

main_methods 
    |- methods.py

而methods.py包含以下内容：

def foo():
    return 'foo'

要使用foo（），您需要以下选项之一：

from main_methods.methods import foo # Call with foo()
from main_methods import methods # Call with methods.foo()
import main_methods.methods # Call with main_methods.methods.foo()

也许您需要（或希望）将methods.py保存在main_methods（例如运行时/依赖项）中，但您只希望导入main_method。

如果将methods.py的名称更改为__init__.py，则可以通过导入main_methods来使用foo（）：

import main_methods
print(main_methods.foo()) # Prints 'foo'

这是因为__init__.py被视为包的一部分。

一些Python包实际上做到了这一点。一个例子是JSON，其中运行import JSON实际上是从JSON包中导入__init__.py（请参阅此处的包文件结构）：

源代码：Lib/json/__init__.py

__init__.py有两个主要原因

为了方便：其他用户不需要知道您的函数在包层次结构（文档）中的确切位置。您的程序包（_P）/__初始__.py文件1.py文件2.py...文件N.py#在__init__.py中从.file1导入*从.file2导入*...从.fileN导入*#在file1.py中def add（）：通过然后其他人可以调用add（）从您的_package导入添加不知道file1的内部函数，例如从您的_package.file1导入添加如果你想初始化一些东西；例如，日志记录（应该放在顶层）：导入logging.configlogging.config.dictConfig（Your_logging_config）