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 import func_name

because application is usually the root directory you run from, not a package name inside itself.

This matters in real programming because projects are split into many files. If you do not understand imports, code becomes hard to run, hard to test, and fragile across environments.

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

from app.folder.file import func_name

result = func_name()
print(result)

If you run from the application folder, this should work.

Running it correctly

From the application directory:

python -m app2.some_folder.some_file

Using -m is often safer than running the file directly because it keeps package imports consistent.

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 file.py as a module.

6. It finds func_name inside that module.

7. The name func_name becomes available in some_file.py.

8. Python executes:

   print(func_name())
   

9. func_name() returns the string:

   "Imported successfully"
   

10. That string is printed.

Common failure point

If you run the script from the wrong directory, Python may not know where app is. Then you may see an error like:

ModuleNotFoundError: No module named 'app'

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 sys.path unless necessary

You may see code like this:

import sys
sys.path.append("..")

This can work, but it is usually a last resort because it makes code harder to maintain.

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

Broken idea:

from ../app/folder/file import func_name

Python imports do not use filesystem syntax like that.

Use dotted module paths:

from app.folder.file import func_name

5. Using circular imports

Example problem:

• file.py imports something from some_file.py
• some_file.py imports something from file.py

This can cause partially loaded modules and confusing errors.

Avoid by moving shared code into a third module.

Import styles in Python

Absolute vs relative imports

For beginners, absolute imports are usually the best choice.

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.