using wildcard imports (from … 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. Furthermore, as a general best practice, import statements should be as specific as possible and should only import what they need.

Anti-pattern

The following code imports everything from the math built-in Python module.

# wildcard import = bad
from math import *

Best practices

Make the import statement more specific

The import statement should be refactored to be more specific about what functions or variables it is using from the math module. The modified code below specifies exactly which module member it is using, which happens to be ceil in this example.

from math import ceil

Import the whole module

There are some cases where making the import statement specific is not a good solution:

  • It may be unpractical or cumbersome to create or maintain the list of objects to be imported from a module

  • A direct import would bind to the same name as that of another object (e.g. from asyncio import TimeoutError)

  • The module that the object is imported from would provide valuable contextual information if it is right next to the object when it’s used.

In these cases, use one of these idioms:

import math
x = math.ceil(y)

# or

import multiprocessing as mp
pool = mp.Pool(8)