How to Import Python Files from a Different Folder

By the end of this page, you will understand how Python imports work across folders, what makes a directory importable, why some imports fail, and how to structure and run your project so one module can correctly import another.

In Python, importing code from another file depends on module paths, packages, and where Python starts running your program.

A Python file like file.py is a module. A folder can act like a package when Python can treat it as part of the import system. Then you can import using dotted paths such as:

from app.folder.file import func_name

The important idea is this:

• Python does not import based on your visual folder tree alone.
• Python imports based on paths it knows about in sys.path.
• The folder you run Python from often determines what top-level imports are available.

In your example, application is the project root. If you run Python from inside that folder, Python can usually see app and app2 as top-level packages or package-like directories.

That means the import inside some_file.py is more likely to be:

from app.folder.file import func_name

not:

from application.app.folder.file  func_name

Think of Python imports like looking up an address in a city.

• A module is a house.
• A package is a street or neighborhood.
• The project root is the city map Python starts with.

If Python starts with the application folder as its map, then it can find:

• app.folder.file
• app2.some_folder.some_file

But asking for application.app.folder.file is like telling Python to find a city called application inside the city map it already started from.

So the key question is not just "Where is the file?" but "What is Python treating as the starting point for imports?"

Basic import syntax

If file.py contains:

def func_name():
    return "Hello from file.py"

then inside some_file.py you would usually write:

from app.folder.file import func_name

print(func_name())

Why this works

If you run your code from the application directory, Python can treat app as a top-level import path.

Example project

application/
├── app/
│   └── folder/
│       └── file.py
└── app2/
    └── some_folder/
        └── some_file.py

app/folder/file.py

def func_name():
    return "Imported successfully"

app2/some_folder/some_file.py

Consider this code in some_file.py:

from app.folder.file import func_name

print(func_name())

And this code in file.py:

def func_name():
    return "Imported successfully"

What happens step by step

1. Python starts running some_file.py.

2. It sees:

   from app.folder.file import func_name
   

3. Python looks through its import paths.

4. If the current project root is application, Python looks for:

   • app/
   • inside that, folder/
   • inside that, file.py

5. Python loads as a module.

Imports across folders are used everywhere in Python projects.

Web applications

A route file may import utility functions from a shared helpers module:

from app.utils.validators import validate_email

Data processing scripts

One script may import cleaning functions from another folder:

from app.transforms.cleaning import normalize_name

APIs and services

A controller may import business logic from a service layer:

from app.services.user_service import create_user

Tests

Test files often import application code from another package:

from app.folder.file import func_name

In all of these cases, correct imports depend on a clear project root and consistent package structure.

In real projects, developers usually avoid random path hacks and instead rely on a clean package layout.

Common patterns

1. Import from a project package

A codebase often has a main package such as app:

from app.folder.file import func_name

2. Run modules from the project root

Instead of this:

python app2/some_folder/some_file.py

developers often do this:

python -m app2.some_folder.some_file

This helps Python resolve imports consistently.

3. Keep shared logic in reusable modules

If multiple parts of the code need the same function, it is placed in a shared module and imported where needed.

4. Use package files when needed

In many codebases, __init__.py files are added to make package boundaries explicit:

application/
├── app/
│   ├── __init__.py
│   └── folder/
│       ├── __init__.py
│       └── file.py
└── app2/
    ├── __init__.py
    └── some_folder/
        ├── __init__.py
        └── some_file.py

This is especially helpful for compatibility and clarity.

5. Avoid modifying unless necessary

1. Including the project root in the import path incorrectly

Broken:

from application.app.folder.file import func_name

Why it fails:

• If application is the folder you run from, it is already the root.
• Python looks inside the root for importable packages.

Better:

from app.folder.file import func_name

2. Running the file from the wrong location

Broken approach:

cd app2/some_folder
python some_file.py

This changes what Python sees as the starting path.

Better:

cd application
python -m app2.some_folder.some_file

3. Forgetting package structure

In some environments or older Python setups, missing __init__.py files can cause confusion.

Safer structure:

app/
├── __init__.py
└── folder/
    ├── __init__.py
    └── file.py

4. Using relative filesystem paths instead of module paths

Import styles in Python

Quick reference

Import from another folder

from app.folder.file import func_name

Recommended way to run

cd application
python -m app2.some_folder.some_file

If imports fail, check

• Are you running Python from the project root?
• Is the import path using module names, not filesystem paths?
• Are you mistakenly including the root folder name in the import?
• Would adding __init__.py files help clarify packages?

Example structure

application/
├── app/
│   └── folder/
│       └── file.py
└── app2/
    └── some_folder/
        └── some_file.py

Likely correct import

from app.folder.file import func_name

Common error

from application.app.folder.file import func_name

Why that error happens

Because application is usually the root folder Python starts from, not part of the import path.

Why does from application.app.folder.file import func_name not work?

Because application is usually the project root, not a package name Python imports from inside itself.

What is the correct import in this folder structure?

Usually:

from app.folder.file import func_name

Should I add __init__.py files?

Often yes. They make package structure clearer and can prevent confusion in some tools and environments.

Why does the import work in one terminal but not another?

Because your current working directory affects Python's import path.

Is python some_file.py different from python -m ...?

Yes. python -m package.module usually handles package imports more reliably.

Can I use relative imports instead?

Yes, but they are usually less beginner-friendly and only work properly inside packages.

Should I edit sys.path to fix imports?

Only if you really need to. A better solution is usually to use a proper project structure and run code from the correct root.

• Python modules — A single .py file becomes importable as a module.
• Python packages — Folders of modules that Python can import from.
• __init__.py — Helps define package structure explicitly.
• Absolute imports — The most common way to import across a project.
• Relative imports — Another import style used inside packages.
• sys.path — The list of locations Python searches for modules.
• python -m — Runs code as a module and helps with package-aware imports.
• ModuleNotFoundError — The common error raised when Python cannot resolve an import.