为什么使用 argparse 而不是 optparse？答案

【问题标题】：Why use argparse rather than optparse?为什么使用 argparse 而不是 optparse？
【发布时间】：2011-03-14 03:49:00
【问题描述】：

我注意到 Python 2.7 文档还包含另一个命令行解析模块。除了getopt 和optparse，我们现在还有argparse。

为什么还要创建另一个命令行解析模块？为什么我应该使用它而不是optparse？是否有我应该了解的新功能？

【问题讨论】：

或者可能不使用，因为自 2012 年以来，Python 有一个简单、强大且真正 cool 的参数解析模块，称为 docopt。 docopt.org
尝试单击它是 optparse 的包装器。

标签： python command-line optparse getopt argparse

【解决方案1】：

从 python 2.7 开始，optparse 已被弃用，并有望在未来消失。

argparse 更好，因为其原始页面 (https://code.google.com/archive/p/argparse/) 上列出了所有原因：

处理位置参数
支持子命令
允许使用替代选项前缀，例如 + 和 /
处理零个或多个和一个或多个样式参数
产生更多信息的使用消息
为自定义类型和操作提供更简单的界面

更多信息也在PEP 389 中，这是argparse 进入标准库的工具。

【讨论】：

一个更简单的自定义类型接口......但整体上一个更复杂的接口。我真的很想知道为什么我什至切换到 optparse，因为 drumroll getopt 会留。是的，没有弃用那只恐龙。嘘。
在 PEP 中提到 optparse 的“纯度”，然后是后来关于添加它的复杂程度的争论，使它听起来像是被编码为像摇滚一样灵活（糟糕）。
子命令界面很差。默认输出没有用，而且很难更改。
请注意，code.google.com 将在几天后进行维护。此处提供更多详细信息的差异：argparse.googlecode.com/svn/trunk/doc/argparse-vs-optparse.html

【解决方案2】：

我为什么要使用它而不是选择解析？他们的新功能是我应该知道吗？

我认为@Nicholas 的回答很好地涵盖了这一点，但不是您开始提出的更多“元”问题：

为什么还有另一个命令行解析模块创建了吗？

当任何有用的模块被添加到标准库时，这是第一个困境：当出现提供相同功能的更好但向后不兼容的方法时，你会怎么做？

您要么坚持使用旧的且公认已超越的方式（通常当我们谈论复杂的软件包时：asyncore vs twisted，tkinter vs wx 或 Qt，...），要么您最终会以多种不兼容的方式来做同样的事情事情（恕我直言，XML 解析器是一个比命令行解析器更好的例子——但email 包与处理类似问题的无数旧方法也相距不远；-)。

您可能会在文档中对“已弃用”的旧方式发出威胁性的抱怨，但是（只要您需要保持向后兼容性）如果不阻止大型、重要的应用程序迁移到更新的应用程序，您就无法真正将其删除Python 版本。

（第二个困境，与您的问题没有直接关系，用一句老话“标准库是好的包死去的地方”进行了总结......每年半年左右发布一次，包不是'非常、非常稳定、不需要比这更频繁地需要发布，实际上可能会因在标准库中“冻结”而遭受重大损失......但是，这真的是一个不同的问题）。

【讨论】：

诚然，您可以为 2.7 之前的 python 安装包含 argparse.py，而不必担心向后不兼容的更改。需要跟踪的额外内容，但它仍然在 argparse.googlecode.com 的标准库之外维护
Argparse 仅适用于某些（利基？）用途。从绝对意义上说，它并不是真的更好，它是不同的。它可以做 optparse 做不到的事情，但它也有回归。我刚刚遇到的一个例子：optparse 默认处理“--”（不确定它是否做了应该做的事情），而 argparse 对此一无所知。
对于迟到以上评论的人，argparse有你设置前缀和名称，大多数解析器都写成parser.add_argument('--long-opt', '-l',...)； '--' 很容易处理，随你喜欢。
@SilverbackNet：看起来你错过了关于“--”的要点。对于标准的 Unix 命令参数解析，出现“--”（本身，而不是作为前缀）意味着后面的内容不再是选项，即使它们以破折号开头。
可以从 cpython 中解开长期弃用的库。无法迁移到更好的捆绑替代品的大型重要应用程序可以直接从 pypi 中提取它们，而其他所有人都将从较小的安装中受益。

【解决方案3】：

添加 Python 的最佳理由是它的 PEP：PEP 389: argparse - New Command Line Parsing Module，尤其是标题为 Why aren't getopt and optparse enough? 的部分

【讨论】：

【解决方案4】：

街区也有新的孩子！

除了已经提到的已弃用的 optparse。 [请勿使用]
还提到了 argparse，这是为不愿意包含外部库的人提供的解决方案。
docopt 是一个值得一看的外部库，它使用文档字符串作为输入的解析器。
click 也是外部库并使用装饰器来定义参数。（我的来源推荐：Why Click）
python-inquirer 用于以选择为重点的工具并基于 Inquirer.js (repo)

如果您需要更深入的比较，请阅读 this，您最终可能会使用 docopt 或 click。感谢凯尔·珀登！

【讨论】：

虽然这是一个有价值的评论，但它仍然是一个评论而不是一个答案.. 对我来说没有反对票，但也没有赞成票！用有价值的文章摘要扩展您的答案，使其成为真正的答案！：meta.stackexchange.com/a/8259/172394
我试图包含我的链接的摘要，我希望现在值得一个好的 stackoverflow 答案。

【解决方案5】：

一开始我和@fmark 一样不愿意从 optparse 切换到 argparse，因为：

我认为差异并没有那么大。
很多 VPS 仍然默认提供 Python 2.6。

然后我看到了这个文档，argparse 优于 optparse，尤其是在谈论生成有意义的帮助消息时：http://argparse.googlecode.com/svn/trunk/doc/argparse-vs-optparse.html

然后我看到@Nicholas 的“argparse vs. optparse”，说我们可以在 python

现在我的两个担忧得到了很好的解决。我写了这篇文章，希望它能帮助有类似心态的其他人。

【讨论】：