![A visual summary explaining the main topic of this post: How to Fix Python’s "ImportError: cannot import name ‘…’ from ‘…’](/images/header_images/overlay_image_python.png)

Introduction

The ImportError: cannot import name '...' from '...' is a common Python error that occurs when an import statement fails. This typically happens due to three main reasons: a circular import, a typo in the name of the function or class being imported, or an incorrect module path. This guide will explain each cause and provide solutions.

1. Cause: Circular Imports

A circular import occurs when two or more modules depend on each other. For example, module_a.py tries to import something from module_b.py, while module_b.py also tries to import something from module_a.py. This creates a dependency loop that Python cannot resolve.

Example

module_a.py:

from module_b import b_func

def a_func():
    print("This is a_func")
    b_func()

a_func()

module_b.py:

from module_a import a_func

def b_func():
    print("This is b_func")

# This will raise an ImportError because a_func is not yet fully defined in module_a
# when module_b tries to import it.

Solution

To fix circular imports, you need to refactor your code to break the dependency cycle.

  • Move the import statement: Sometimes, moving the import inside the function that needs it can solve the problem. This is known as a local import.
  • Restructure your code: Move the shared functionality to a third module that both module_a and module_b can import from without creating a circular dependency.
  • Use interfaces or dependency injection: For more complex applications, consider using design patterns that reduce coupling between modules.

2. Cause: Typo or Non-existent Name

This error can also occur if you are trying to import a name (function, class, or variable) that does not exist in the specified module. This is often due to a simple typo.

Example

my_module.py:

def calculate_sum(a, b):
    return a + b

main.py:

# Typo: 'calculate_sum' is misspelled as 'calculate_total'
from my_module import calculate_total 

# This will raise: ImportError: cannot import name 'calculate_total' from 'my_module'

Solution

  • Check for typos: Carefully check the spelling of the name you are trying to import and ensure it matches the definition in the source module.
  • Verify the name exists: Make sure the function, class, or variable is actually defined in the module you are importing from.

3. Cause: Incorrect Module Path or Name

If the module itself is not found or if there’s a naming conflict (e.g., your script has the same name as a standard library module), you might get this error.

Example

If you have a file named math.py in your project and you try to import a function from the standard math library, it might try to import from your local file instead.

Solution

  • Check sys.path: Ensure that the directory containing your module is in Python’s search path. You can inspect sys.path to see where Python is looking for modules.
  • Avoid naming conflicts: Do not name your scripts with the same names as standard Python libraries (e.g., math.py, os.py, sys.py).
  • Ensure __init__.py exists: If you are importing from a package (a directory of modules), make sure it contains an __init__.py file (though this is less strict in Python 3.3+ with namespace packages).

By systematically checking for these common causes, you can effectively resolve the ImportError: cannot import name '...' from '...' error.

Professional Depth Check

For “How to Fix Python’s "ImportError: cannot import name ‘…’ from ‘…’"“, the practical standard is not whether the reader can repeat one instruction once. Treat the topic as a reproducible debugging procedure: verify interpreter path, virtual environment, package version, and input file or data boundary before drawing a conclusion. The result should be written as a small decision record, because future readers need to know which fact was observed, which assumption was used, and which condition would change the answer.

Evidence That Makes the Guidance Reliable

Use objective evidence before changing a workflow. Good evidence includes python --version, python -m pip show, the full traceback, and a minimal script. If two pieces of evidence conflict, keep the conflict visible instead of smoothing it over. For example, a successful quick fix is still weak evidence if the same input, account, dependency, or device state has not been tested again. A durable article should help the reader distinguish a confirmed fix from a plausible fix.

Review Table

Review Item What To Confirm Why It Matters
Scope The exact case covered by this article Prevents over-applying the advice
Baseline The state before any change Makes rollback and comparison possible
Change The smallest action taken Reduces hidden side effects
Result The observed output after the change Separates evidence from expectation
Recheck When to revisit the conclusion Keeps the post accurate over time

Edge Cases and Failure Modes

The main risks are fixing the symptom while leaving the root cause, and mixing unrelated changes into the same test. When the situation involves production data, personal information, money, health, legal rights, or security recovery, the conservative path is to stop and collect evidence before applying a broad fix. The same title can describe very different cases, so the reader should compare their environment with the assumptions in the post before copying commands or decisions.

Maintenance Standard

Recheck this guidance after dependency, operating-system, or build-tool changes. A useful update does not need to rewrite the entire post; it should confirm whether the examples, links, commands, screenshots, and decision criteria still match current behavior. If the old conclusion remains valid, record the check date. If it changes, explain what changed and why the previous advice is no longer enough.

Continue with these related posts from the same topic area.

Leave a comment

You may also enjoy