A wildcard import, written as from modulename import *, places a module’s exported names directly in the importing namespace, so callers omit the module prefix. section 10.3
Apply the main rules carefully:
- Import all public names by default; identifiers beginning with an underscore are excluded. section 10.3 section 10.5
- Honor the module or package’s __all__ list when it exists; that list controls which names are imported. section 10.3 section 18.4
- Avoid relying on it when explicit origins matter: later wildcard imports can replace earlier names, creating clashes and obscuring where names came from. section 4.7.5 section 10.3
- Do not expect recursive package imports; importing a package name does not automatically import names from its subpackages. section 18.4
Public and private names
Given modtest.py with f, a, _g, and _b, from modtest import * makes f and a available. Calls to _g(3) or references to _b raise NameError, while explicit imports such as from modtest import _g remain possible. section 10.5
A collision to avoid
Importing math and then cmath with wildcard syntax can replace commonly named functions from math. Prefer import cmath and call cmath.sqrt(-1) when the module origin should remain visible. section 4.7.5
from modtest import * f(3) 3 _g(3) --------------------------------------------------------------------------- NameError Traceback (most recent call last) <ipython-input-15-787abdf7161a> in <cell line: 1>() ----> 1 _g(3) NameError: name '_g' is not defined a 4 _b --------------------------------------------------------------------------- NameError Traceback (most recent call last) <ipython-input-17-8352e74fe22a> in <cell line: 1>() ----> 1 _b NameError: name '_b' is not defined
Inspect the interactive results showing which names wildcard import exposes and which underscore-prefixed names remain undefined. section 10.5
