【问题标题】:Should the use of subprocess.Popen and subprocess.call be avoided if possible?如果可能的话,是否应该避免使用 subprocess.Popen 和 subprocess.call ?
【发布时间】:2018-10-25 16:55:38
【问题描述】:

我正在做一个项目,通过使用ImageMagick进行简单的图像处理和比较

现在,为了执行我的命令,我正在使用 python subprocess 模块:

color_space = ...
evaluate_sequence = ...
output_file_name = ...

convert_cmd = ["magick", "convert", "-colorspace", color_space.name] + queue + \
            ["-evaluate-sequence", evaluate_sequence.name, output_file_name]

subprocess.call(convert_cmd)

我最近了解到ImageMagick 有 Python 包装器。特别是,我正在调查MagickWand

在性能、安全性等方面重构我的代码以不使用 subprocess 模块有很大的好处吗?

我认为子进程调用比使用MagickWand 之类的调用更易读/更简单,但如果还有其他好处我想切换。

【问题讨论】:

    标签: python python-3.x subprocess imagemagick wand


    【解决方案1】:

    是否应该尽可能避免使用 subprocess.Popen 和 subprocess.call?

    不值得。您共享的代码是一项简单的任务,您已经在 python 中以清晰易读的方式进行了模板化。为什么要让您的解决方案因单个快速任务的附加依赖性和复杂性而变得复杂。 convert 实用程序今天也适用于您,但明天可能还有另一个外部实用程序。

    在性能、安全性等方面重构我的代码以不使用 subprocess 模块有很大的好处吗?

    我认为这只是通过不调用系统调用对性能的最小好处,但包括动态加载共享库的 C-API 包装器模块也大致相同。另外,根据委托,ImageMagick 本身可能会调用系统调用。

    出于安全考虑,无论哪种方式,您的应用程序仍需负责清理变量。我也建议...

    • 通过 IM 阅读 Security Policies
    • 确保subprocess.call 不能被外部资源访问。 (即,如果解决方案在网络服务器上,则将任务移动到远程队列工作者)
    • 改进错误和警告处理。它们比您想象的更常见!

    切换参数

    我能想到的常见理由...

    • 减少 I/O,因为图像数据已经在 python 内存中。
    • 任务是基于算法的动态任务(如 meme 生成器)。
    • 常见的像素迭代器
    • OCR/CV 预处理器

    同样,您确实没有理由证明切换的合理性。至少今天不会。

    【讨论】:

      猜你喜欢
      • 2011-11-16
      • 2018-01-14
      • 2016-03-26
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-10-05
      • 2010-12-13
      • 2015-08-23
      相关资源
      最近更新 更多