Different Ways to Import Python Modules

Python provides four ways to import Python modules, and each one has a distinct effect on how names enter your program's namespace. Understanding these styles is not just a matter of syntax preference. The choice you make affects how readable your code is six months later, how easy it is for another developer to trace where a function comes from, and whether your module's namespace is clean or cluttered with names from a dozen different sources.

The four styles are: importing the whole module, importing specific names from a module, importing everything with a wildcard, and importing with an alias. Each one is legal Python, each one has scenarios where it is the right choice, and each one can be misused in ways that make code harder to maintain. After reading about the fundamentals of importing modules in Python, understanding when to reach for each style is the next step toward writing imports that help rather than hinder.

Style 1: Import the whole module

This is the simplest and most common form, and it is the recommended default for most situations. You write the import keyword followed by the module name, and every function, constant, and class inside that module becomes accessible through the module name prefix. If you import the math module this way, you write math.sqrt to call the square root function and math.pi to access the pi constant. The prefix tells you instantly where each name comes from, with no need to scroll to the top of the file to check the import block.

python

import math
 
radius = 5
area = math.pi * (radius ** 2)
print(f"Area: {area:.2f}")

The prefix is the main reason this style is preferred in professional codebases. When you read a line of code, you know immediately which module provides each function, and you can trace a bug back to its source without hunting through a list of individual name imports. There is a minor cost in that you type the module prefix before every call, but for modules used a handful of times per file, this cost is negligible compared to the clarity benefit.

Style 2: Import specific names

This form pulls one or more specific names from a module directly into your local namespace, without the module prefix. You write from followed by the module name, then import, then a comma-separated list of the names you want. After this import, those names are available without any prefix, and you can call them as if they were defined locally. This style is appropriate when a specific name from a module is central to the logic of your file and you call it frequently enough that the prefix genuinely hurts readability.

python

from math import sqrt, pi
 
radius = 5
area = pi * (radius ** 2)
root = sqrt(area)

The risk of this style is that it creates what appear to be local names that are actually imported from elsewhere. If a reader encounters a bare function call on line 200 of a long file, they need to check the import block at the top to confirm where it comes from. The more names you import this way, the harder it becomes to trace each one to its origin. A reasonable guideline is to use this style for at most three or four names from the same module in a single file, and only for names that are unambiguous and well-known in the Python community.

Style 3: Import with an alias

This form imports a module and gives it an alternative name using the as keyword. The module is fully loaded, but you refer to it by the alias instead of the original name. This style serves two distinct purposes: shortening long module paths and resolving naming conflicts. When a module is nested deep inside a package hierarchy, the fully qualified import path might be five or six segments long. An alias reduces that to a short, readable name that still carries meaning.

There is also a strong convention in the Python community for certain widely used third-party libraries. The numpy library is conventionally imported as np, pandas as pd, and matplotlib.pyplot as plt. These conventions are so universal that deviating from them makes your code harder for other Python programmers to read, even though the alias is technically arbitrary. When working with libraries that have established import aliases, follow the community convention.

Style 4: The wildcard import

The wildcard import, written with an asterisk, imports every public name from a module directly into the local namespace. After this import, every function and constant the module exports becomes available without a prefix. This style is convenient in an interactive Python session where you want quick access to everything a module provides without typing prefixes, but for production code that other people will read and maintain, the wildcard import is problematic.

The fundamental issue is that it dumps an unpredictable number of names into your namespace. Anyone reading the code cannot tell which names came from which module without consulting the module's documentation. It also creates a risk of name collisions: if two modules both export a function with the same name and you wildcard-import both, the second import silently overwrites the first, and you may not notice the bug until runtime. Avoid this style in any file that you intend to commit to version control.

Choosing the right combination for a real file

A well-structured Python file typically uses the plain import style as the backbone, with the from-import style used sparingly for a few well-known names. The top of a data processing script might import csv and json with the plain style because their functions are called only a few times, while importing a couple of specific datetime names because they appear throughout the file. A widely used third-party library might get a conventional alias. No single module should be imported in more than one style in the same file; pick one and be consistent.

The import style you choose as a consumer is also influenced by how the module's author designed the public API. A module that exports a small number of well-chosen names works well with the from-import style because every importable name is familiar and unambiguous. A module that exports dozens of names with overlapping purposes is better imported with the plain style so the prefix serves as documentation. When you design your own modules, keep this consumer experience in mind. A module with five clearly named functions invites focused imports where appropriate. A module with forty functions forces consumers to use the plain import style to avoid namespace chaos. For guidance on structuring modules so imports stay manageable, the article on organizing Python code with packages connects these import mechanics to project architecture.