Introduction

Calling a function from another Python file is just importing the module and then using the function from that module. The tricky part is usually not the function call itself, but understanding how Python resolves module names and how project structure affects imports.

Once you see each .py file as a module, the problem becomes much simpler: import the module, call the function, and keep script-only code behind a main guard so imports do not trigger unexpected side effects.

That mental model is more useful than memorizing one import statement, because it scales from tiny scripts to larger multi-package projects.

Import a Module from the Same Directory

If the two files live side by side, import the module using the filename without .py.

# math_utils.py
def add(a, b):
    return a + b

1# main.py
2import math_utils
3
4result = math_utils.add(2, 3)
5print(result)

This style is explicit and scales well because the module name stays visible at the call site.

Import the Function Directly

If you prefer shorter calls, import the function itself:

# math_utils.py
def add(a, b):
    return a + b

1# main.py
2from math_utils import add
3
4print(add(2, 3))

This is convenient for small helper modules, but it also makes the imported name look local, so use it carefully in larger files.

Structure Larger Projects as Packages

Once a project has several files, package structure matters more:

1project/
2  app/
3    __init__.py
4    helpers.py
5    runner.py

Then runner.py can import from helpers.py like this:

from app.helpers import greet

print(greet("Nina"))

And helpers.py might look like:

def greet(name):
    return f"Hello, {name}"

This approach keeps imports clear as the project grows.

It also makes testing easier, because modules can be imported and exercised in isolation instead of behaving like one large script.

Protect Script-Only Code

Importing a module executes its top-level statements. That surprises many beginners when prints, file access, or network calls run just because a helper file was imported.

Use the main guard:

1def greet(name):
2    return f"Hello, {name}"
3
4
5def main():
6    print(greet("world"))
7
8
9if __name__ == "__main__":
10    main()

With that guard in place, the module can be imported safely without running the script-only code path.

Avoid Random sys.path Hacks

If an import fails, the fix is usually not appending random directories to sys.path. First check:

• whether the files are in the expected location
• whether you are running the command from the correct project root
• whether the package structure is valid
• whether the virtual environment is active

Path hacks can hide the real issue and make the code behave differently on another machine.

If the project is meant to be reused by others, a clean package layout is almost always a better long-term fix than teaching every developer a custom launch command.

Common Pitfalls

• Writing the .py extension in the import statement.
• Putting executable code at module top level and then wondering why it runs during import.
• Creating circular imports where two modules depend on each other directly.
• Running the script from the wrong directory and then blaming the import syntax.
• Using sys.path manipulation instead of fixing package layout.

Summary

• Import the module or the function from the other .py file.
• Use import module when you want clearer namespaces.
• Use from module import name when a short call site is appropriate.
• Protect direct-execution logic with if __name__ == "__main__":.
• As projects grow, prefer package-based imports over ad hoc path fixes.