Should wildcard import be avoided?

社会主义新天地 提交于 2019-11-26 10:32:34

The answer to your question's title is "yes": I recommend never using from ... import *, and I discussed the reasons in another very recent answer. Briefly, qualified names are good, barenames are very limited, so the "third option" is optimal (as you'll be using qualified names, not barenames) among those you present.

(Advantages of qualified names wrt barenames include ease of faking/mocking for testing purposes, reduced to nullified risk of unnoticed errors induced by accidental rebinding, ability to "semi-fake" the top name in a "tracing class" for the purpose of logging exactly what you're using and easing such activities as profiling, and so forth -- disadvantages, just about none... see also the last-but-not-least koan in the Zen of Python, import this at the interactive interpreter prompt).

Equally good, if you grudge the 7 extra characters to say QtCore.whatever, is to abbreviate -- from PyQt4 import QtCore as Cr and from PyQt4 import QtGi as Gu (then use Cr.blah and Gu.zorp) or the like. Like all abbreviations, it's a style tradeoff between conciseness and clarity (would you rather name a variable count_of_all_widgets_in_the_inventory, num_widgets, or x? often the middle choice would be best, but not always;-).

BTW, I would not use more than one as clause in a single from or import statement (could be confusing), I'd rather have multiple statements (also easier to debug if any import is giving problem, to edit if you change your imports in the future, ...).

There are also good cases for import *. ie. it's common for Django developers to have many config files and chain them using import *:

settings.py:
FOO = 1
BAR = 2
DEBUG = False

test_settings.py:
from settings import *
DEBUG = True

In this case most disadvantages of import * become advantages.

luc

Python doc says:

Although certain modules are designed to export only names that follow certain patterns when you use import *, it is still considered bad practise in production code.

It can have side effects and be very difficult to debug

Personnaly, I am using import rather than from import because I find awful big declarations at the beginning of the file and I think it keeps the code more readable

import PyQt4

PyQt4.QtCore

If the module name is too long and can be renamed locally with the as keyword. For example:

 import PyQt4.QtCore as Qc

I hope it helps

I use the "import *" for the PyQt modules I use, but I put them in their own module, so it doesn't pollute the namespace of the user. e.g.

In qt4.py:

 from PyQt4.QtCore import *
 from PyQt4.QtGui import *

Then use it like this

 import qt4
 app = qt4.QApplication(...)

import for PyQt4 is a special case.
sometimes I'll choose the "first option" for quick and dirty coding, and turn it to the "second option" when the code grows longer and longer.
namespace collision maybe not a big deal here, I haven't see other package'name starts with a big "Q". and whenever I finish a PyQt4 script. convert"from PyQt4.QtGui import *" to sth. like "

from PyQt4.QtGui import (QApplication, QDialog, QLineEdit, QTextBrowser,
                         QVBoxLayout)

" just FYI, parentheses for multi-line import is handy here.

I am too absolutely against import * in the general case. In the case of PySide2, one of the rare exceptions applies:

from PySide2 import *

is the pattern to import all known modules from PySide2. This import is very convenient, because the import is always correct. The constant is computed from the CMAKE generator. Very helpful when quickly trying something in the interactive console, but also in automated testing.

For advanced usage, it makes also sense to use the PySide2.__all__ variable directly, which implements this feature. The elements of PySide2.__all__ are ordered by dependency, so first comes QtCore, then QtGui, QtWidgets, ... and so on.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!