为什么使用 argparse 而不是 optparse？

Question

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

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

Answer 1

从 python 2.7 开始，optparse< /a> 已弃用，希望将来会消失。

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

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

更多信息也位于 PEP 389，它是 argparse 进入标准库的工具。

Answer 2

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

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

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

当任何有用的模块被添加到标准库中时，这是第一个问题：当出现一种更好但向后不兼容的提供相同类型功能的方法时，您该怎么办？

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

您可能会在文档中抱怨旧方法被“弃用”，但是（只要您需要保持向后兼容性）您就无法真正将它们删除，除非阻止大型、重要的应用程序迁移到较新的 Python 版本。

（第二个困境，与你的问题没有直接关系，用一句老话来概括：“标准库是好的软件包消亡的地方”......大约每年半发布一次，软件包不是很好， 非常稳定，不需要比这更频繁的发布，实际上可能会因为被“冻结”在标准库中而受到严重影响......但是，这确实是一个不同的问题） 。

Answer 3

添加 Python 的最佳理由是其 PEP：PEP 389：argparse - New命令行解析模块，特别是标题为 为什么 getopt 和 optparse 还不够？

Answer 4

街区里还有新孩子！

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

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

Answer 5

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

1. 我认为差异并没有那么大。
2. 相当多的VPS仍然默认提供Python 2.6。

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

然后我看到“argparse 与 optparse" 作者：@Nicholas，说我们可以在 python <2.7 中使用 argparse （是的，我以前不知道这一点。）

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