Why this rule?

Wildcard imports bind many names into the current namespace and execute all top‑level module initialization. This can slightly increase import time, parsing, and memory. Multiplied across many modules or cold starts, this adds avoidable CPU/energy. It also hurts analyzability and maintainability by obscuring where names come from.

This rule is advisory for eco‑design: the effect is modest compared to algorithmic issues, so severity is Minor.

Eco‑performance and energy

What changes (small but measurable in some contexts): - Star imports perform mass‑binding of all exported names into the importer’s namespace (O(N) assignments). - This adds a little extra CPU at import time and slightly increases the importer’s namespace size in memory.

When it can matter (accumulates across many imports/cold starts): - Many files using star imports across a large codebase. - Cold‑start heavy workloads (serverless/functions, frequent short‑lived jobs). - In data and AI projects, small import-time costs can repeat many times and add up.

When it is typically negligible: - Long‑running services (module import is cached in sys.modules; mass‑binding cost is paid once).

Performance measurement example

A simple benchmark comparing import methods shows measurable differences:

import timeit

# Normal import
print("normal import:", timeit.timeit("import math", number=1000))

# Wildcard import (using exec to avoid syntax restrictions)
def test_wildcard_import():
    exec("from math import *")

print("from import *:", timeit.timeit(test_wildcard_import, number=1000))

Typical results on Python 3.12: - Normal import: ~0.0018 seconds (1000 iterations) - Wildcard import: ~0.0245 seconds (1000 iterations)

This represents approximately a 13x performance difference for import operations, demonstrating the overhead of wildcard imports.

Rule scope

  • Flags top‑level statements: from module import *.

  • Focuses on readability/maintainability with secondary eco‑impact (CPU/memory at import time).

Exceptions (when it’s acceptable)

  • Package aggregation files (init.py) that re‑export a curated API.

  • If the target module defines all, making the export surface explicit.

  • Generated code, quick scripts/REPL/notebooks, or educational material.

Non‑compliant

from utils import *
process(data)

Compliant alternatives

# Explicit named imports
from utils import parse, process

# Or module import with alias
import utils as u
u.process(data)

Public API re‑exports

# In package/__init__.py
from .parse import parse
from .process import process
__all__ = ["parse", "process"]

References