为何contextlib._RedirectStream被实现为可重入上下文管理器？

先看代码里的核心逻辑：每次调用__enter__时，会把当前的标准流对象（比如sys.stdout）追加到_old_targets列表，然后替换成新目标；调用__exit__时，会从列表末尾弹出最后一个保存的流对象，恢复回去。注释说这是为了让上下文管理器可重入，具体的实际价值和适用场景如下：

什么是可重入的上下文管理器？ #

可重入指的是同一个上下文管理器实例可以被多次嵌套使用，每一次进入/退出上下文都能正确维护流的状态，不会因为重复使用而导致状态混乱。

实际益处与适用场景 #

1. 嵌套复用同一个重定向实例 #

假设你有一个已经创建好的redirect_stdout实例，需要在多层嵌套的代码块里重复使用它：

import sys
from contextlib import redirect_stdout
import io

# 创建一个指向内存流的重定向实例
mem_out = io.StringIO()
redirector = redirect_stdout(mem_out)

with redirector:
    print("外层：输出到内存流")
    with redirector:
        print("内层：继续输出到内存流")
    # 内层退出后，stdout会恢复到外层的状态（也就是mem_out）
    print("外层：依然输出到内存流")

# 外层退出后，stdout恢复为原始控制台输出
print("回到控制台输出")

如果不用列表存储_old_targets，而是用单个变量，那么第二次__enter__会覆盖第一次保存的原始流对象，内层__exit__时直接恢复到原始流，外层退出时就会把已经是原始流的状态再次设置，导致逻辑错误。而列表的栈结构（append/pop）刚好匹配嵌套上下文的“后进先出”，每一层都能正确保存和恢复当前的流状态。

2. 递归或嵌套调用中复用实例 #

如果有一个工具函数，内部使用了同一个重定向实例，且这个函数可能被递归调用或者嵌套调用：

def recursive_log(redirector, depth):
    if depth == 0:
        return
    with redirector:
        print(f"递归层级：{depth}")
        recursive_log(redirector, depth-1)

# 调用递归函数
recursive_log(redirector, 3)

这种场景下，列表的栈结构能保证每一层递归进入时都保存当前的流状态，退出时逐层恢复，不会因为递归导致流状态错乱。

3. 动态切换重定向目标的场景 #

有时候你可能需要临时切换重定向目标，之后再切回之前的状态，复用同一个实例时，列表能帮你记录每一次切换前的流状态：

# 先重定向到文件A
file_a = open("a.log", "w")
redirector = redirect_stdout(file_a)
with redirector:
    print("写入文件A")
    # 临时切换到文件B
    file_b = open("b.log", "w")
    redirector._new_target = file_b
    with redirector:
        print("写入文件B")
    # 内层退出后，恢复到文件A
    print("继续写入文件A")

这里每一次进入上下文都会把当前的流（第一次是原始stdout，第二次是file_a）存入列表，退出时依次恢复，保证每一步的流状态都正确。

总结 #

用列表存储_old_targets本质是用栈结构来维护嵌套上下文的状态，让同一个重定向实例可以安全地被多次嵌套使用，无论是递归调用、多层代码块嵌套，还是动态切换重定向目标的场景，都能避免流状态混乱，确保每一层上下文退出时都能正确恢复到进入前的流状态。

内容的提问来源于stack exchange，提问作者vitalizzare