Python concurrent.interpreters 怎样创建解释器实例

如果你在 Python 3.14 中想把一段工作放进独立的解释器上下文，入口就是 from concurrent import interpreters，再调用 interpreters.create()。它返回一个 Interpreter 对象，后续可以用 prepare_main() 准备数据，用 exec() 执行代码，或用 call() 调用函数；结束后要显式调用 close()。

官方地址：https://docs.python.org/3.14/library/concurrent.interpreters.html

最小可用路径是“创建句柄—准备少量可传递数据—调用或执行—finally 中关闭”。多解释器默认提供隔离，不会因为创建了 Interpreter 就自动产生线程；真正的并发需要再配合线程或更高层的执行器。

先看清 Python 3.14 带来的变化

concurrent.interpreters 是 Python 3.14 新增的标准库模块，用较高层的 Python API 管理同一进程中的多个解释器。每个解释器都有自己的导入状态、内建对象和执行上下文，默认不直接共享大多数可变 Python 对象。

这和创建进程不完全一样：解释器仍在同一进程内，切换成本和资源形态不同；它也不是线程池，创建解释器本身不会启动后台线程。官方文档还特别提醒，第三方扩展对多解释器的支持并不齐全，因此迁移时要把依赖兼容性列为前置条件。

用 create() 得到一个独立解释器

创建动作很小，但建议立刻把生命周期写成 try/finally。这样即使后续调用抛出解释器相关异常，也不会把一个已经不用的解释器留在进程里。

from concurrent import interpreters

# 创建一个空闲的解释器句柄；这一步不会自动启动线程。
interp = interpreters.create()
try:
    # 只准备简单、可复制的数据，作为目标解释器的主模块名字。
    interp.prepare_main({"task_name": "parse"})

    # 在目标解释器的 __main__ 命名空间中执行代码。
    interp.exec("result = task_name.upper()")
finally:
    # 任务完成后显式结束解释器，避免生命周期悬挂。
    interp.close()

prepare_main() 的作用是向目标解释器的 __main__ 绑定名字；它不是把当前解释器里的字典变成两个解释器共同持有的可变对象。对于简单参数可以采用复制或序列化方式传递，对于复杂对象则应先设计清楚边界。

exec、call 和 call_in_thread 怎么选

如果代码天然是字符串，使用 exec()；如果已有函数，希望拿到返回值，优先考虑 call()；如果已经决定在线程中执行，才使用 call_in_thread()。这三个接口解决的是调用形态，不应混同为三种自动并发模式。

from concurrent import interpreters

# 这个函数不依赖当前解释器中的可变全局状态，便于传给目标解释器。
def build_label(prefix, number):
    # 让调用结果只依赖显式参数，降低跨解释器传递的不确定性。
    return f"{prefix}-{number}"

interp = interpreters.create()
try:
    # call() 在目标解释器中执行函数，并把返回值带回当前解释器。
    label = interp.call(build_label, "job", 7)
    print(label)

    # call_in_thread() 返回线程对象；调用方仍要负责等待线程结束。
    thread = interp.call_in_thread(build_label, "async", 8)
    thread.join()
finally:
    # 只有确认不再使用该解释器时，才进行最终清理。
    interp.close()

需要注意两件事。第一，目标解释器中的异常会以解释器相关异常形式反馈，调用边界应保留明确的错误处理。第二，函数、参数和返回值都要满足可传递条件；不能因为写法像普通函数调用，就假设任意对象都能直接穿过解释器边界。

用 create_queue() 传递消息，而不是共享可变对象

多个解释器真正协作时，通常需要消息通道。模块提供 create_queue()，可以建立跨解释器队列；调用方通过 put() 和 get() 传递少量消息。多数对象会通过 pickle 复制，None、bool、bytes、str、数字以及满足条件的元组更容易处理，但不能把普通可变对象当作同步共享状态。

from concurrent import interpreters

# 队列是显式消息边界；maxsize 为 0 表示不设置有限容量。
queue = interpreters.create_queue()
interp = interpreters.create()
try:
    # 把简单消息放入队列，避免直接共享当前解释器中的可变容器。
    queue.put({"kind": "parse", "value": "demo"})

    # 目标解释器只接收队列句柄和可传递参数。
    def consume(message_queue):
        # get() 取出一条消息，业务代码再按消息类型分派处理。
        return message_queue.get()

    message = interp.call(consume, queue)
    print(message["kind"])
finally:
    # 队列由调用方管理，解释器也要独立关闭。
    interp.close()

如果对象无法被传递，接口会抛出 NotShareableError 或相关的解释器异常。解决思路不是强行把对象塞过去，而是把消息设计成更小的值对象，或者把共享需求改成明确的队列协议。

关闭、异常和迁移前检查

最小清理动作就是 interp.close()。它会结束并销毁解释器；如果解释器仍在运行，或者目标已不存在，调用方需要按实际异常决定是等待、记录还是停止后续操作。文章示例使用 finally，是为了让清理路径不依赖业务调用是否成功。

从旧代码迁移时，可以按下面的清单逐项判断：

• 运行环境是否为 Python 3.14 或更高版本，并且部署平台不是不支持该模块的 WASI 场景。
• 第三方 C 扩展是否明确支持多解释器；官方文档指出并非所有 PyPI 包都已经兼容。
• 跨解释器传递的数据是否可以复制或序列化，是否需要用队列替代直接共享。
• 是否真的需要多解释器；只有创建句柄而没有线程或执行器配合，并不会自动获得并发。
• 所有解释器是否都有清晰的关闭点，异常路径是否仍会进入 finally。

常见问题

创建 Interpreter 会自动开启并行执行吗？

不会。它首先代表一个隔离的执行上下文，默认在当前线程中切换和调用。需要并发时，还要显式使用线程、call_in_thread() 或 Python 3.14 的 InterpreterPoolExecutor 等更高层方案。

为什么不能直接把一个可变字典当作共享状态？

解释器之间默认隔离，多数对象会复制而不是共享同一份可变内存。应优先传递简单值或通过 create_queue() 发送消息，并在协议中规定字段和生命周期。

什么时候不适合马上迁移到多解释器？

当依赖大量尚未确认兼容的第三方扩展、任务很小却需要频繁复制数据，或者系统没有清晰的消息边界时，不宜只因为“多核”这个词就迁移。先盘点依赖、测量初始化和通信成本，再决定是否采用。

总结

concurrent.interpreters 的创建路径并不复杂：create() 拿到句柄，prepare_main() 准备数据，按需求使用 exec()、call() 或 call_in_thread()，消息协作使用 create_queue()，最终在 finally 中 close()。真正的迁移难点在对象传递、第三方扩展兼容性和生命周期设计，而不是把普通线程代码机械替换成另一个类名。