【问题标题】：What's the correct convention of importing external packages?导入外部包的正确约定是什么？
【发布时间】：2021-03-12 12:00:37
【问题描述】：

我想构建自己的包，我在其中使用包numpy。对于更直观的示例，让我们考虑：

import numpy as np
def my_fun(x, y):
    return np.linspace(x, y)

我的问题是：有没有更好的方法来包含外部包？我在包numpy 的源代码中看到它们使用完全相同的约定，即在函数脚本中导入包。我们有更好的方法吗？
例如有另一个 .py 文件只包含导入的包

【问题讨论】：

【解决方案1】：

根据 PEP 8 风格指南：

导入通常应该在单独的行中

# Correct:
import os
import sys
# Wrong:
import sys, os

尽管这样说是可以的：

# Correct:
from subprocess import Popen, PIPE

导入总是放在文件的顶部

就在任何模块 cmets 和文档字符串之后，模块全局变量和常量之前。

进口应按以下顺序分组：

您应该在每组导入之间放置一个空行。

如果导入系统配置不正确（例如当包内的目录最终位于 sys.path 上时），它们通常更具可读性并且表现更好（或至少提供更好的错误消息）：

import mypkg.sibling
from mypkg import sibling
from mypkg.sibling import example

但是，显式相对导入是绝对导入的可接受替代方案，尤其是在处理复杂的包布局时，使用绝对导入会不必要地冗长：

from . import sibling
from .sibling import example

标准库代码应避免复杂的包布局并始终使用绝对导入。

不应使用隐式相对导入，并且已在 Python 3 中删除。

通常可以这样拼写：

from myclass import MyClass
from foo.bar.yourclass import YourClass

如果此拼写导致本地名称冲突，则明确拼写：

import myclass
import foo.bar.yourclass

并使用“myclass.MyClass”和“foo.bar.yourclass.YourClass”。

它们使命名空间中存在哪些名称变得不清楚，从而使读者和许多自动化工具感到困惑。通配符导入有一个可辩护的用例，即重新发布一个内部接口作为公共 API 的一部分（例如，用可选加速器模块中的定义覆盖接口的纯 Python 实现，以及哪些定义将被被覆盖是事先不知道的）。

以这种方式重新发布名称时，以下关于公共和内部接口的准则仍然适用。

【讨论】：