Should wildcard import be avoided?
Question:
I’m using PyQt and am running into this issue. If my import statements are:
from PyQt4.QtCore import *
from PyQt4.QtGui import *
then pylint gives hundreds of “Unused import” warnings. I’m hesitant to just turn them off, because there might be other unused imports that are actually useful to see. Another option would be to do this:
from PyQt4.QtCore import Qt, QPointF, QRectF
from PyQt4.QtGui import QGraphicsItem, QGraphicsScene, ...
and I end up having 9 classes on the QtGui line. There’s a third option, which is:
from PyQt4 import QtCore, QtGui
and then prefix all the classes with QtCore or QtGui whenever I use them.
At this point I’m agnostic as to which one I end up doing in my project, although the last one seems the most painful from my perspective. What are the common practices here? Are there technical reason to use one style over the other?
Answers:
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
practice in production code.
It can have side effects and be very difficult to debug
Personally, 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
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.
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 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(...)
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.
I’m using PyQt and am running into this issue. If my import statements are:
from PyQt4.QtCore import *
from PyQt4.QtGui import *
then pylint gives hundreds of “Unused import” warnings. I’m hesitant to just turn them off, because there might be other unused imports that are actually useful to see. Another option would be to do this:
from PyQt4.QtCore import Qt, QPointF, QRectF
from PyQt4.QtGui import QGraphicsItem, QGraphicsScene, ...
and I end up having 9 classes on the QtGui line. There’s a third option, which is:
from PyQt4 import QtCore, QtGui
and then prefix all the classes with QtCore or QtGui whenever I use them.
At this point I’m agnostic as to which one I end up doing in my project, although the last one seems the most painful from my perspective. What are the common practices here? Are there technical reason to use one style over the other?
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
practice in production code.
It can have side effects and be very difficult to debug
Personally, 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
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.
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 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(...)
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.