写Python代码这事儿，刚入门那会儿，哪儿懂什么结构啊、模块啊，就是一个文件从头撸到尾。几百行、几千行，密密麻麻堆在一起。找个函数？眼睛都快找瞎了。想把某块儿功能给别人用？复制粘贴，改来改去，累死了。那时候心里就嘀咕，这不对劲啊，肯定有更好的办法。后来才慢慢明白，原来“好代码”就是要拆的，要模块化。这就自然而然地引出了一个核心问题：python怎么调用其他python代码？说白了，就是在一个Python程序里，怎么“使唤”或者“借用”另一个Python文件里的东西。

最正统、最Pythonic的方式，毫无疑问就是用import。就像你想读一本特定领域的书，得先去图书馆把它“借”出来。在Python里，这个“书”就是你要调用的那个模块（module）。一个.py文件，通常就可以看作是一个模块。

import module_name：这是最直接的。比如你有个文件叫 my_utils.py 里头写了一堆工具函数，想在 main.py 里用，就在 main.py 开头写 import my_utils。用的时候就得带着模块名，my_utils.some_function()。规规矩矩，清晰明白，知道这函数是哪儿来的。我觉得这种方式挺好的，不容易重名，也不会把你的当前命名空间搞得乱七八糟。

import module_name as alias：有时候模块名太长了，或者你想换个更顺嘴的名字，就可以用 as 给它起个别名（alias）。import numpy as np 就是经典例子。以后用 np.array() 就行，多省事儿！

from module_name import specific_item：如果你只需要某个模块里的特定函数、类或者变量，不想把整个模块都“请”进来，就可以用 from ... import ...。比如 from my_utils import process_data。这样以后直接调用 process_data() 就行，不用带模块名了。省事儿是省事儿，但得小心，万一你当前文件里也有个叫 process_data 的函数，就冲突了。这就是为什么有些人不太喜欢这种方式，觉得不够明确。

from module_name import *：这个嘛，就有点儿“懒”了。直接把一个模块里所有非以下划线开头的名字都一股脑儿地导入到你的当前命名空间。from my_utils import *。这下好了，你可以直接用 my_utils 里的所有公开函数和变量了，看起来写代码是快了点儿。但是！这是个大大的但是！强烈不推荐！尤其是在大型项目里。你根本不知道一个模块里到底藏了多少东西，这样一股脑儿导进来，命名冲突的风险巨大，代码也变得难以阅读和调试。一个函数突然冒出来，鬼知道它是从哪个模块来的？就像一股脑儿把图书馆所有书都搬到你家，找本书比之前还费劲。

所以你看，光是导入一个模块，就有这么多讲究。我个人是倾向于用 import module_name 或者 import module_name as alias，需要特定东西时才用 from ... import specific_item，而且会明确导入什么。那个 import *？能不用就不用，除非是些特定场景下（比如一些交互式环境或者明确知道模块内容很少很安全）才会考虑。

说到 import，有个绕不开的大麻烦就是模块的查找路径。Python怎么知道你说的 my_utils 模块在哪儿呢？它不是瞎找的，有一套自己的规则。它会按顺序去几个地方找：首先是当前脚本所在的目录；然后是你的 PYTHONPATH 环境变量里指定的那些目录；最后是Python安装时自带的那些标准库目录。这个查找路径列表，你可以通过 import sys; print(sys.path) 看到。

刚开始写跨文件调用的时候，简直要被这个路径搞疯了。本地跑得好好的，一放到服务器上，或者目录结构稍微一调整，立马 ModuleNotFoundError！那种感觉，就像你让人去个地方，只说了个名字，没告诉他在哪个城市哪个区，人家当然找不着啊。

解决路径问题，除了设置 PYTHONPATH 环境变量（这玩意儿有时候挺烦的，尤其是在不同环境之间切换），更推荐的方式是合理组织你的项目结构，把相关的模块放在一起，形成包（Package）。一个包就是一个包含 __init__.py 文件的目录。这个 __init__.py 文件可以是空的，但它的存在告诉Python：“嘿，我是一个包！”。

有了包，导入的时候路径就更清晰了。比如你的结构是 my_project/utils/my_utils.py，那你在 my_project/main.py 里想用 my_utils，就可以写 from utils import my_utils，或者 import utils.my_utils。这样层级分明，不容易出错。当然，运行 main.py 的时候，得确保 my_project 这个目录是在 sys.path 能找到的地方，最简单就是直接在 my_project 的上一级目录运行你的 main.py。

有时候，你想调用的不是一个模块里的函数或类，而是一个完全独立的Python脚本。想象一下，你写了一个数据处理的脚本 process_data.py，它自己就能跑，接收命令行参数，输出结果。现在你在另一个脚本 main.py 里，想“远程遥控”这个 process_data.py 跑起来，甚至把 process_data.py 的输出抓回来。这时候，光用 import 就力有不逮了。因为 import 是把代码加载到同一个解释器进程里运行，而你想做的，是让操作系统另起一个进程去执行那个脚本。

这时候就轮到 subprocess 模块出场了！这玩意儿简直是操作系统交互的利器。你可以用它来运行任何命令，当然也包括 python another_script.py 这样的命令。

subprocess.run() 是比较新的、推荐的用法。它能执行一个命令，然后等着它结束，把它的退出码、标准输出（stdout）、标准错误（stderr）都抓回来。

```python
import subprocess
import sys # 需要用到 sys.executable

try:
# 假设你要执行的脚本叫 another_script.py
# sys.executable 会找到当前运行的Python解释器路径
result = subprocess.run([sys.executable, 'another_script.py', 'arg1', 'arg2'],
capture_output=True, text=True, check=True)

print("子进程输出：")
print(result.stdout)
if result.stderr:
    print("子进程错误输出：")
    print(result.stderr)

except subprocess.CalledProcessError as e:
print(f"子进程执行失败，退出码 {e.returncode}")
print(f"错误输出：{e.stderr}")
except FileNotFoundError:
print("没找到 another_script.py 脚本或者 python 解释器")
```

这段代码就展示了怎么用 subprocess.run 跑另一个 Python 脚本，并且捕获它的输出。capture_output=True 让你能拿到 stdout 和 stderr，text=True 让输出变成字符串而不是字节码，check=True 会在子进程返回非零退出码时抛异常，这样你就能知道它是不是正常运行完了。

你还可以用 subprocess.Popen()，它更灵活，可以在子进程还在运行的时候就和它交互（比如通过管道发送输入，或者非阻塞地读取输出），但用起来也更复杂些，需要自己管理进程，等着它结束，处理进程间的输入输出流。

相比较于 import 是代码层面的复用和组织，subprocess 更像是在操作系统层面让两个独立的程序“对话”或“接力”。它的优势在于被调用的脚本是完全独立的，环境相对隔离，不会影响当前主进程的命名空间。缺点嘛，启动一个新进程总是有开销的，而且通过命令行参数和标准输入/输出进行交互，不如函数调用那么直接和灵活。但话说回来，有些场景下，比如你想跑一个别人提供的、只能独立运行的工具脚本，subprocess 就是你的救星。

至于那些老掉牙的 os.system() 和 os.popen()？能不用就别用了。它们功能有限，安全性差，错误处理也不方便，用 subprocess 才是王道。

还有一种方式，听起来很酷炫，但用起来得十二万分小心，那就是 exec() 和 eval()。这两个是Python的内置函数，可以直接执行字符串形式的Python代码。

exec(code_string) 可以执行任意的代码语句块，比如定义函数、类、变量，甚至运行循环和条件判断。执行后，这些定义会影响当前的命名空间。

eval(expression_string) 则是用来计算一个Python表达式的值，然后返回这个值。它只能是表达式，不能是语句（比如 if 或 for 就不行）。

```python

exec 例子

code = """
def greet(name):
print(f"Hello, {name}!")
"""
exec(code)
greet("World") # 现在 greet 函数就在当前命名空间里了

eval 例子

x = 10
y = 20
expression = "x + y * 2"
result = eval(expression) # 计算 10 + 20 * 2 = 50
print(result)
```

看起来很灵活对不对？你可以动态地生成代码然后执行。但问题是，如果这个 code_string 或者 expression_string 是来自外部不可信的输入（比如用户在网页上填的），那就完蛋了！恶意的用户可以构造任何Python代码，比如删除你的文件、访问敏感数据、执行系统命令...想干啥干啥。这就相当于在你家里开了一个无限制的后门。所以，除非你百分之百确定要执行的代码字符串是安全的、可控的，否则千万不要使用 exec() 或 eval()。这可不是闹着玩儿的。

相比 import 和 subprocess，exec/eval 更像是把另一段代码“粘贴”到当前位置原地执行。它没有独立的命名空间（或者说可以通过参数控制，但默认是在当前或指定命名空间执行），也不是另起一个进程。它直接操纵的是当前的解释器状态。这种能力强大到有点儿吓人，感觉就像直接在别人大脑里运行指令一样。

说了这么多，python怎么调用其他python，其实就是围绕着代码的复用和组织这个核心来的。大多数时候，你想用别的Python文件里的功能，最好的方式就是把它当成一个模块或包，然后用 import 语句导入，优雅又安全。这是Pythonic的首选。

如果你需要运行一个独立的脚本，或者要进行操作系统层面的交互，subprocess 模块是你的得力助手，它可以帮你启动另一个进程，并且相对可控。

至于 exec 和 eval，除非你明确知道自己在干什么，并且能确保代码来源绝对安全，否则碰都别碰！风险太大了。

选择哪种方式，完全取决于你的具体需求。是想复用代码逻辑？是想跑一个独立的工具？还是想动态执行一些特定代码？不同的场景，不同的工具。

回想当年，为了让我的几个小脚本能互相配合干活，简直是瞎折腾。有时候硬生生地把代码复制来复制去，改得头皮发麻；有时候发现 import 报错找不着文件，对着 sys.path 发呆；有时候又怕subprocess 乱七八糟的输出搞砸我的主程序。一步步趟过来，才慢慢理解这些机制背后的逻辑。现在看来，把代码写得模块化、有清晰的职责，真的是太重要了。不仅仅是为了“调用别人”或“被别人调用”，更是为了代码本身的可读性、可维护性和可测试性。

所以下次再写Python，如果你的文件开始变得臃肿，或者你想用之前写好的某个函数、某个类，停下来想想，是不是该把它拆成一个独立的模块了？是不是该用 import 来优雅地引入了？这不仅仅是技术问题，更是一种代码设计的哲学。让你的代码像乐高积木一样，一块一块的，清晰、独立，但又能互相协作，拼出更强大的功能。这才是一个Pythoner应该追求的境界吧！