Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Should wildcard import be avoided?

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?

like image 378
Colin Avatar asked Sep 01 '10 04:09

Colin


People also ask

Why should we avoid wildcard imports?

Wildcard imports help us avoid a long list of imports in our code. Therefore, this impacts the readability of code as the reader may have to scroll a lot in every source code file before reaching the code that shows the logic.

Do wildcard imports affect performance?

There is no performance difference between a specific import and a wildcard import declaration. The information for the classes in imported package is not read in at compile time or run time unless the class is used in the program.

How do I disable wildcard imports in Intellij?

The solution is to go to Preferences ( ⌘ + , on macOS / Ctrl + Alt + S on Windows and Linux) > Editor > Code Style > Java > Imports tab set Class count to use import with '*' and Names count to use static import with '*' to a higher value. Any value over 99 seems to work fine.

What is wildcard import in Python?

import * ) When an import statement in the pattern of from MODULE import * is used it may become difficult for a Python validator to detect undefined names in the program that imported the module.


2 Answers

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, ...).

like image 136
Alex Martelli Avatar answered Oct 01 '22 10:10

Alex Martelli


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.

like image 37
Tomasz Wysocki Avatar answered Oct 01 '22 10:10

Tomasz Wysocki