为什么使用argparse而不是optparse?

Python添加的基本原理的最佳来源是它的PEP: argparse -新的命令行解析模块，特别是题为为什么getopt和optparse不够用?的部分

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

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

• 处理位置参数
• 支持sub-commands
• 允许像+和/这样的替代选项前缀
• 处理零或多个和一个或多个样式参数
• 产生更有信息的使用消息
• 为自定义类型和操作提供更简单的接口

更多的信息也在PEP 389中，它是argparse进入标准库的载体。

为什么我要用它而不是 optparse吗?他们的新特点是我吗 应该知道什么?< / p >

@Nicholas的回答很好地涵盖了这一点，我认为，但不是你开头的更“元”的问题:

为什么还有另一个命令行 解析模块已创建?< / p >

当任何有用的模块添加到标准库中时，这就是第一个难题:当出现一种实质上更好但向后不兼容的方式来提供相同的功能时，您该怎么办?

要么你坚持使用旧的、无可否认已经被超越的方法(通常当我们谈论复杂的包时:asyncore vs twisted, tkinter vs wx或Qt，…)，要么你最终用多种不兼容的方法来做同样的事情(XML解析器，恕我之见，是一个比命令行解析器更好的例子——但是email包vs无数处理类似问题的旧方法也不是太远;-)。

你可能会在文档中抱怨旧的方法被“弃用”了，但是(只要你需要保持向后兼容性)你不能在不阻止大型的、重要的应用程序迁移到新的Python版本的情况下真的把它们去掉。

(第二个困境，与你的问题没有直接关系，可以用一句老话来概括:“标准库是好包死的地方”……每一年半左右发布一次，那些非常不太稳定、不需要更频繁发布的包实际上会因为被“冻结”在标准库中而遭受重大损失……但是，这真的是另一个问题)。

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

1. 我还以为差别没那么大呢。
2. 相当多的VPS仍然默认提供Python 2.6。

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

然后我看到@Nicholas的“Argparse vs. optparse”，说我们可以在python <2.7中使用argparse(是的，我以前不知道这一点)。

现在我的两个顾虑都得到了很好的解决。我写这篇文章是希望它能帮助其他有类似想法的人。

街区里也有新孩子!

• 除了已经提到的弃用的optparse。[不要使用]
• argparse也被提到，这是一个解决方案的人不愿意包括外部库。
• docopt是一个值得一看的外部库，它使用文档字符串作为输入的解析器。
• 点击也是外部库，使用装饰器定义参数。(我的来源推荐:为什么点击)
• python-inquirer用于选择重点工具，并基于inquiry .js (回购)

如果你需要更深入的比较，请阅读这，你可能最终使用docopt或点击。感谢凯尔·博登!