Back to Blog
Python

Python Import As: Aliasing Modules and Names

Learn how to use python import as to alias modules, functions, and classes, improve readability, and avoid namespace conflicts in your code.

Pythonimportaliasingmodulescode readability
A visual metaphor of Python import aliasing, showing two distinct names pointing to the same module object, with clean code-like blocks and arrows.

The python import as syntax lets you bind an imported module, function, class, or attribute to a different name in the current namespace. It is a core feature of the language that appears in nearly every non-trivial Python project. The basic form is straightforward:

import module_name as alias

For example, the common practice of importing the numpy library as np is written as:

import numpy as np

After this statement, np refers to the numpy module, and you can call np.array, np.linspace, and so on. The original name numpy is not bound in the current namespace unless you also import it without an alias.

The Basic Syntax of import as

The as keyword works with both import statements and from ... import statements. With a plain import, you alias the module itself:

import pandas as pd import matplotlib.pyplot as plt

With from ... import, you alias a specific attribute, such as a function, class, or variable:

from datetime import datetime as dt from collections import OrderedDict as OD

You can also alias multiple names in one statement by separating them with commas:

from os.path import join as path_join, split as path_split

This syntax is equivalent to writing two separate import statements. The alias is local to the module or function where the import appears. If you import inside a function, the alias is only visible within that function's scope.

Why Alias an Import?

Aliasing serves three primary purposes: brevity, conflict avoidance, and clarity. The most common reason is to shorten a long module name so that repeated references are less verbose. For instance, import tkinter as tk avoids typing tkinter many times in GUI code. Similarly, import statistics as stats shortens the name without losing meaning.

Conflict avoidance is critical when two modules export the same name. Suppose you need both json.load and pickle.load. Without aliasing, the second import would overwrite the first. With aliases, you can keep both accessible:

import json import pickle # Later in code json.load(file) pickle.load(file)

If you only need the load functions, you can alias them directly:

from json import load as json_load from pickle import load as pickle_load

Clarity is a more subtle benefit. A well-chosen alias can make code more readable by indicating the purpose of the imported object. For example, from decimal import Decimal as Price is not typical, but it can be useful in a domain-specific context where the custom name carries more meaning. However, this practice can also obscure the underlying type, so it should be used with restraint.

Aliasing Modules vs. Aliasing Names from a Module

There is an important distinction between import module as alias and from module import name as alias. The former binds the entire module object to the alias, so you must use attribute access to reach its contents. The latter binds a single attribute directly, so you can use the alias as a standalone name.

Consider the two approaches for the math module:

import math as m print(m.sqrt(16)) # works from math import sqrt as square_root print(square_root(16)) # works

In the first case, m is a module object. In the second, square_root is a function object. This distinction affects how you use the alias and how the name is resolved at runtime. Aliasing a module does not import its submodules automatically; you still need to reference them explicitly, such as m.cos or m.pi.

A common mistake is to assume that import package.submodule as alias gives you a short name for the submodule. It does, but the alias refers to the submodule, not the package. For example:

import os.path as path print(path.join('a', 'b')) # works

Here, path is the os.path module, not the os package. This is often exactly what you want, but it can confuse readers who expect path to be a function.

Common Patterns and Idiomatic Usage

The Python community has established several idiomatic aliases that appear in almost every project. The most well-known are:

  • import numpy as np
  • import pandas as pd
  • import matplotlib.pyplot as plt
  • import seaborn as sns
  • import tensorflow as tf
  • import requests as rq (less common but seen)

These aliases are so widely recognized that they become part of the language's cultural vocabulary. Using them in your own code makes it easier for other developers to understand your imports without reading the full module name.

Another pattern is to use aliasing to avoid shadowing built-in names. For example, if you need to work with the id function but also have a variable named id, you can alias the built-in:

from builtins import id as builtin_id id = 42 print(builtin_id([1, 2])) # uses the built-in

This is a niche use case, but it shows how aliasing can resolve naming collisions.

Pitfalls and Misunderstandings

One common pitfall is assuming that aliasing changes the module's internal name. It does not. The module is still registered in sys.modules under its original full name. The alias is only a local binding. This means that if two different modules are aliased to the same name in different scopes, they remain distinct.

Another issue is that aliasing can hide the source of a name, making code harder to trace. If you read from service import get_data as fetch, you might later wonder what fetch actually does. The alias should be chosen to aid comprehension, not to obscure it.

A more technical concern is the use of aliases in type hints. When you annotate a variable with an aliased type, the type checker still sees the original type. For example:

from typing import List as ListType def process(items: ListType[int]) -> None: pass

This works, but it can confuse readers who expect ListType to be a custom type. It is usually clearer to import the type under its original name or use a more descriptive alias.

Finally, be aware that import as does not affect the import system's caching. Importing a module under multiple aliases does not load it twice; Python caches the module object in sys.modules. So import numpy as np and import numpy as npy both refer to the same module instance, and any state within that module is shared.

Performance and Maintainability Considerations

There is no measurable runtime cost to using import as; it is a simple name binding. The performance impact is identical to a normal import. The real cost is in maintainability. A poorly chosen alias can make code harder to search and refactor. For instance, if you alias from config import settings as cfg, and later you need to find all usages of settings, a text search for settings will miss every cfg reference. This can complicate debugging and code review.

To mitigate this, follow these guidelines:

  • Use aliases that are shorter but recognizable. import numpy as np is fine because np is universally understood. Avoid cryptic aliases like import numpy as n unless you are in a very constrained context.
  • Keep aliases consistent across a project. If one file uses import pandas as pd, another should not use import pandas as pnd.
  • Prefer aliasing modules over aliasing individual functions when you need many attributes from the same module. This keeps the namespace clean and makes the origin of each call obvious.
  • When aliasing a function or class, choose a name that reflects its role rather than its original name. For example, from datetime import datetime as utc_now is acceptable if you always use it to get the current UTC time, but it can mislead if you later use it for other purposes.

In large codebases, a common practice is to centralize imports in a dedicated module and re-export aliases. This pattern, sometimes called a

python import as: Practical Usage and Code Examples | RYUSLOG DEV