我想知道在Python应用程序中导入包的首选方式。我的包结构如下：
project.app1.models
project.app1.views
project.app2.models
project.app1.views导入了project.app1.models和project.app2.models。有两种方法可以做到这一点。
第一种是使用绝对导入：
import A.A
import A.B.B
或者使用直接相对导入，如PEP 328在Python 2.5中引入的：
# explicit relative
from .. import A
from . import B
最pythonic的方法是什么？
Python相关导入不再被强烈反对，但在这种情况下强烈建议使用absolute_import。
请参见此讨论引用Guido本人的话：
“这不是历史吗？在新的相对导入语法实现之前，相对导入存在各种问题。短期解决方案是建议不要使用它们。长期解决方案是实现一个明确的语法。现在是时候撤回反建议了。当然，不要过分——我仍然认为它们是一种习得的口味；但是它们有它们的位置。”
OP正确地链接了PEP 328，其中提到：
提出了几种用例，其中最重要的是能够重新排列大型软件包的结构，而无需编辑子软件包。此外，一个包内的模块如果没有使用相对导入则无法轻松地导入自身。
同时请参考几乎相同的问题何时或为什么在Python中使用相对导入
当然，这仍然是一种口味问题。虽然使用相对导入可以更轻松地移动代码，但这也可能意外地破坏某些东西；而重命名导入并不那么困难。
要强制执行PEP 328的新行为，请使用：
from __future__ import absolute_import
import localfile 不再起作用，只能使用 from . import localfile）。为了保持清洁和未来的证明，建议使用absolute_import。ValueError: Attempted relative import in non-package。我对此和对__main__机制的任何其他提议都是-1。 唯一的用例似乎是运行恰好位于模块目录中的脚本，这一直被看作是反模式。 要让我改变主意，你必须说服我它不是这样。
在stackoverflow上可以找到关于这个问题的详细讨论。对于Python 3，以下内容非常全面：
绝对导入。根据 PEP 8：
强烈不建议在包内部使用相对导入。 对于所有导入，请始终使用绝对包路径。 即使现在 Python 2.5 完全实现了 PEP 328 [7]， 其显式相对导入的风格仍然被积极地不推荐； 绝对导入更具可移植性和通常更易读。
显式相对导入是一种不错的语言特性（我想是这样），但它们远不如绝对导入明确。更易读的形式为：
import A.A
import A.B.B
特别是当您导入多个不同的命名空间时。如果查看一些包含从包内导入的项目/教程，它们通常遵循这种风格。
您采用更加明确的方式所花费的额外按键次数将在未来节省他人（也可能是您自己）大量时间，当他们尝试弄清楚您的命名空间时（特别是如果您迁移到3.x，在其中一些包名称已更改的情况下）。
相对导入不仅可以使您在以后重命名包时无需更改数十个内部导入，而且我还通过它们成功解决了涉及循环导入或命名空间包等问题的某些问题，因为它们不会将Python“回到顶部”以从顶级命名空间重新开始搜索下一个模块。
python setup.py install或python setup.py develop），在这种情况下，我会fork源代码并将其作为git子模块添加。当这些软件包在其自身的软件包名称上使用绝对导入时，它们的导入会失败。唯一的解决方法是使用显式相对导入。我认为应该鼓励这种做法。 - CMCDragonkai
import .baz- 这只是PEP中描述的许多类似情况之一。 - Stefano__future__ import absolute_import。我将在最后一段更新我的答案，并可能扩展我的理由，但PEP比我更详细和清晰；-) - Stefano