这是构建模块的Pythonic方式吗？

Question

Suppose that I was writing an application that used a number of GUI controls that I'm writing Python code for. Each control is described by a class, and I want to aggregate all of those classes into a module, called gui . As a seasoned C/C++ developer, it makes most sense to me to separate the class implementations by file, like this:

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

Where, in the above, the specification of the MainWindow class would be in MainWindow.py . If I lay the files out in this way, however, then the syntax to get at those classes looks like:

import gui
w = gui.MainWindow.MainWindow()

which seems redundant. A way around this limitation is to edit gui/__init__.py to say:

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

which brings the classes into the gui module namespace. I can then access them as follows:

w = gui.MainWindow()

Is this typically done? Does it have sufficient Pythonicity to be considered appropriate in the community? One drawback that I can see is that I need to be sure to keep gui/__init__.py as I add new submodules to the gui module; I don't like manual steps like that.

Thoughts and/or suggestions of how to better address this would be great.

Answer 1

不要导入* （除非您确定不存在冲突;此规则可以针对包作者进行修改），但当然这是一个可接受的解决方案。

Answer 2

Probably you have noted these PEPs and documentation sites before:

• PEP8 -- Style Guide for Python Code
• PEP 20 -- The Zen of Python
• Packages

So the only thing I can add to this is not to use import * . One example:

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

While you validly argue that you know what you are doing. You cannot assume that all of the potential re-users that import * from your package know what they're shadowing while they tear down the final namespace barrier between their and your code. This gives nasty errors. See also:

Now what happens when the user writes from sound.effects import * ? Ideally, one would hope that this somehow goes out to the filesystem, finds which submodules are present in the package, and imports them all. This could take a long time and importing sub-modules might have unwanted side-effects that should only happen when the sub-module is explicitly imported. Docs

and

(import * is not an option ;-) PEP328

and

Namespaces are one honking great idea -- let's do more of those! PEP20

But these are only guidelines/recommendations/personal preferences, and there certainly exist edge cases when these do not apply.