The Significance of all in Python Modules
The __all__ variable in Python is a special module-level
list of strings that explicitly defines the public interface of a module
or package. By declaring __all__, developers control which
symbols—such as functions, classes, and variables—are exported when a
consumer uses wildcard imports like from module import *.
Beyond restricting namespace pollution during imports,
__all__ serves as clear documentation for a module's
intended public API, prevents accidental exposure of internal utilities,
and guides static analysis tools, IDEs, and automated documentation
generators.
Controlling Wildcard Imports
By default, when a script executes from module import *,
Python imports all names defined in the module that do not begin with an
underscore (_). While prefixing helper functions with an
underscore denotes them as private, this default behavior can still
unintentionally expose imported third-party libraries or standard
library modules that were only brought in to support the module's
implementation.
When __all__ is defined, Python ignores the default
underscore-based rule and exports only the names explicitly
listed in the collection:
# math_tools.py
import math # Internal dependency
__all__ = ['add', 'calculate_circle_area']
def add(a, b):
return a + b
def calculate_circle_area(radius):
return math.pi * (radius ** 2)
def _internal_helper():
passExecuting from math_tools import * imports only
add and calculate_circle_area. Neither
_internal_helper nor the imported math library
enters the calling namespace, ensuring the importer's environment
remains clean and free of naming collisions.
Defining an Explicit Public API
Python emphasizes readability and explicit declarations. While PEP 8
generally discourages the use of wildcard imports in production code,
__all__ remains valuable as a formal contract. It
explicitly signals to other developers which components are stable,
supported, and meant for consumption, and which are implementation
details subject to change.
Managing Package-Level Exports
In multi-file packages containing an __init__.py file,
__all__ plays a critical role in structuring how submodules
are exposed. If a user runs from package import *, Python
does not automatically import all submodules found in the package
directory; it only imports submodules explicitly listed in the
__init__.py's __all__ sequence. This prevents
expensive or unnecessary imports from running automatically when the
package is initialized.
Tooling, Linters, and Static Analysis
Modern development workflows rely heavily on automated tooling. Type
checkers (such as Mypy and Pyright), linters (like Flake8 and Ruff), and
documentation generators (such as Sphinx) interpret __all__
to understand a library's structure:
- Re-exporting Symbols: In typed Python, importing a
symbol into an
__init__.pyfile does not automatically mark it as re-exported. Listing the symbol in__all__informs type checkers that the export is intentional, silencing "unused import" warnings. - Auto-Documentation: Tools like Sphinx and
pydocuse__all__to determine which objects to include in generated API documentation, omitting internal logic automatically. - Code Completion: IDEs leverage
__all__to refine code-completion suggestions, prioritizing public API members over internal imports.