0

假设我正在编写一个应用程序，该应用程序使用了许多我正在为其编写 Python 代码的 GUI 控件。每个控件都由一个类描述，我想将所有这些类聚合到一个名为gui. 作为一名经验丰富的 C/C++ 开发人员，对我来说，按文件分隔类实现是最有意义的，如下所示：

gui/MainWindow.py
gui/Widget1.py
gui/Widget2.py

其中，在上面，MainWindow类的规范将在MainWindow.py. 但是，如果我以这种方式布置文件，那么获取这些类的语法如下所示：

import gui
w = gui.MainWindow.MainWindow()

这似乎是多余的。解决此限制的一种方法是编辑gui/__init__.py说：

from gui.MainWindow import *
from gui.Widget1 import *
from gui.Widget2 import *

它将类带入gui模块命名空间。然后我可以按如下方式访问它们：

w = gui.MainWindow()

这通常会完成吗？它是否有足够的 Pythonicity 被认为在社区中是合适的？gui/__init__.py我可以看到的一个缺点是，当我向模块添加新的子模块时，我需要确保保留gui；我不喜欢这样的手动步骤。

关于如何更好地解决这个问题的想法和/或建议会很棒。

4

2 回答 2

2

不要导入*（除非你确定不会有冲突；这个规则可以适用于包作者），但当然这是一个可以接受的解决方案。

于 2012-04-19T18:34:17.340 回答
0

您之前可能已经注意到这些 PEP 和文档站点：

所以我唯一可以添加的就是不要使用import *. 一个例子：

>>> from pylab import *
>>> any(False for i in range(5))
True

当您有效地争辩说您知道自己在做什么时。您不能假设import *您包中的所有潜在重用用户都知道他们正在隐藏什么，同时他们拆除了他们和您的代码之间的最终命名空间障碍。这会产生令人讨厌的错误。也可以看看：

现在当用户写入时会发生什么from sound.effects import *？理想情况下，希望以某种方式传递到文件系统，找到包中存在哪些子模块，然后将它们全部导入。这可能需要很长时间，并且导入子模块可能会产生不希望的副作用，这些副作用仅在显式导入子模块时才会发生。文档

和

（导入 * 不是一个选项 ;-) PEP328

和

命名空间是一个很棒的想法——让我们做更多的事情！PEP20

但这些只是指南/建议/个人偏好，当这些不适用时，肯定存在极端情况。

于 2012-04-19T19:14:27.147 回答