能否简化@contextlib.contextmanager定义上下文管理器的写法？

首先得明确：你设想的写法逻辑上和原有的try/yield/finally完全不符，技术上也无法实现等价的效果，原因如下：

1. 现有写法的核心逻辑 #

用@contextlib.contextmanager装饰的生成器函数，本质是用yield作为分割点：

• yield之前的代码对应上下文管理器的__enter__方法（进入上下文时执行）
• yield之后的代码对应__exit__方法（退出上下文时执行，无论业务代码是否抛出异常）
• try/finally是为了确保yield之后的清理代码一定会执行，哪怕yield块（即用户使用上下文时的业务代码）抛出异常。

2. 你设想写法的逻辑错误 #

你写的代码：

enter_action(...)
with context_magic(...):  # equivalent to try/yield/finally
    exit_action(...)

这里的exit_action()会在进入with块时立即执行，而不是等到业务代码执行完之后。因为with语句的执行流程是：

1. 调用context_magic().__enter__()
2. 执行with块内的所有代码（也就是你的exit_action()）
3. 调用context_magic().__exit__()

这和原有的try/yield/finally逻辑完全相反——原逻辑是先执行业务代码（yield暂停时，用户的with块代码运行），再执行清理代码（finally里的exit_action），而你的写法会先跑清理代码，再跑业务代码，完全起不到上下文管理器的作用。

3. 技术上是否能实现类似的简洁写法？ #

如果只是想封装try/yield/finally的结构，可以写一个辅助函数，但并不会比原写法更简洁或易读：

from contextlib import contextmanager

def wrap_context(enter, exit):
    enter()
    try:
        yield
    finally:
        exit()

@contextmanager
def my_context():
    yield from wrap_context(enter_action, exit_action)

但这种写法并没有减少代码量，反而增加了一层封装，违背了Python“显式优于隐式”的设计原则——原写法的try/finally一眼就能看出是保证清理代码执行，封装后反而需要读者理解辅助函数的逻辑。

总结 #

@contextlib.contextmanager的try/yield/finally写法看似繁琐，但胜在逻辑清晰、符合Python的设计哲学。你设想的写法不仅逻辑错误，也无法实现等价的上下文管理效果，所以官方不会提供这样的语法糖。

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