检查系统调用结果的Pythonic写法是否符合Python惯用规范

这种写法不是Python开发者处理同类任务的惯用写法，本身还藏着几个容易出问题的bug，实际用起来健壮性甚至可能不如直接调用原生API。

• 自定义的subprocess方法逻辑完全冗余：while proc.poll() is None的轮询没有任何实际作用，进入循环后第一次调用proc.wait()就会阻塞到进程退出直接返回，和直接调用wait没有区别。更严重的是你创建管道后完全没有读取输出内容，只要命令输出量超过系统管道缓冲区大小（一般是64KB左右），进程就会直接卡死，属于subprocess使用的经典坑。
• 错误判断太粗糙：dnf list installed返回非0的原因有很多，可能是包没装，也可能是dnf本身报错、仓库元数据损坏、权限不足，你全部归因为「包未安装」，很容易出现误判。同时方法直接丢弃了所有命令输出，真出问题的时候没有任何日志可以排查。
• 异常设计不合理：直接抛基类Exception，上层捕获的时候没法区分具体错误类型，写恢复逻辑的时候很容易把无关错误也兜住。
• 不必要的shell=True：如果没有拼接shell管道、通配符的需求，开shell=True不仅有性能损耗，还存在命令注入的风险。
• 代码本身还有语法错误：check_package_installed方法里的raise语句末尾多写了一个右括号，直接运行会报语法错误。

1. 优先用标准库自带的高层API，不要自己重复封装Popen的底层逻辑
   Python 3.5之后官方推荐所有subprocess场景优先用subprocess.run()，自带参数可以直接实现执行结果校验、输出捕获，不用自己写轮询、wait逻辑。
   举个最常见的封装示例：

import subprocess

def run_cmd(cmd, shell=False):
    """执行命令，返回(执行是否成功, 命令输出内容)"""
    try:
        ret = subprocess.run(
            cmd,
            shell=shell,
            stdout=subprocess.PIPE,
            stderr=subprocess.STDOUT,
            text=True,
            check=True
        )
        return True, ret.stdout.strip()
    except subprocess.CalledProcessError as e:
        return False, e.stdout.strip()

2. 业务判断逻辑要做精准校验
   比如检查RPM包是否安装，优先用更底层、不受仓库状态影响的rpm -q 包名命令，除了判断返回码，最好也校验输出格式，避免把其他错误误判为包未安装。如果逻辑复杂，甚至可以直接用对应系统的Python绑定库，不用硬拼命令行调用。

3. 用精准的异常类型
   不要抛泛化的Exception，可以针对业务场景自定义异常，比如PackageNotInstalledError，上层捕获的时候可以精准处理对应场景的错误，不会误捕获其他无关异常。

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