Introduction

There are several ways to make one Python file run another, but the right choice depends on what you actually mean by "run." Sometimes you want to reuse functions from another file in the same process, and sometimes you want to launch a completely separate Python process. Those are different operations, and treating them the same leads to brittle code.

Use import When You Want Reuse

If the other file contains functions or classes you want to call, the cleanest solution is to turn it into a module and import it.

1# helper.py
2
3def greet(name: str) -> None:
4    print(f"Hello, {name}!")

1# main.py
2import helper
3
4helper.greet("Mark")

This keeps both files in the same Python process. It is the best approach when the second file is part of the same application and you want normal function calls, shared objects, and testable design.

One important detail is that top-level code in the imported file runs at import time. That is why reusable modules should usually protect executable demo code with if __name__ == "__main__":.

Use subprocess When You Want a Separate Program

If the second file should run as its own program with a separate process, use subprocess. This is the right tool when the called script has its own command-line interface, environment, or failure boundary.

1import subprocess
2import sys
3
4result = subprocess.run(
5    [sys.executable, "worker.py", "--mode", "fast"],
6    check=True,
7    capture_output=True,
8    text=True,
9)
10
11print(result.stdout)

Using sys.executable matters because it ensures the child script runs with the same Python interpreter as the parent. That avoids a long list of virtual-environment and path problems.

runpy Exists, but It Is a Niche Tool

Python also has the runpy module, which can execute another module as if it were run as a script. This is occasionally useful for tooling, but it is usually not the first choice for application code.

import runpy

runpy.run_path("worker.py", run_name="__main__")

This still runs in the current interpreter, which means it shares process state in ways that can be surprising. For ordinary software design, import or subprocess is usually clearer.

What to Avoid

A lot of beginners discover patterns like this:

exec(open("worker.py").read())

Technically, it executes the file, but it is rarely a good design. It mixes namespaces, makes debugging harder, and creates security problems if the target code is not fully trusted. In most real projects, this is the wrong abstraction.

How to Choose

A practical rule is:

• use import for reusable code in the same application
• use subprocess for running another script as a separate program
• use runpy only when you specifically need script-style execution inside the same interpreter

Once you frame the problem that way, the choice becomes much simpler.

Common Pitfalls

• Using exec() when an import or subprocess call would be safer and clearer.
• Forgetting that imported modules execute top-level code on first import.
• Launching a subprocess when a normal function call would be simpler.
• Hard-coding python instead of using sys.executable.
• Mixing application logic and script entry-point logic in the same file without clear boundaries.

Summary

• 'import is the best option for code reuse in the same Python process.'
• 'subprocess is the best option for running another script as a separate program.'
• 'runpy is a specialized middle ground, not the default answer.'
• Avoid exec() for ordinary cross-file execution.
• Decide first whether you need reuse or process isolation, then choose the tool.