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

Argparse在其原始页面(https://code.google.com/archive/p/argparse/):)中列出了所有更好的原因

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

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

关于添加Python的基本原理，最好的来源是它的PEP: PEP 389: argparse -新的命令行解析模块，特别是题为“为什么getopt和optparse不够?”

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

Argparse在其原始页面(https://code.google.com/archive/p/argparse/):)中列出了所有更好的原因

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

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

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

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

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

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

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

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

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

一开始我和@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 <2.7中使用argparse(是的，我以前不知道这一点)。

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

街区里也有新孩子!

除了已经提到的已弃用的optparse。[不要使用] 还提到了Argparse，它是为不愿意包含外部库的人提供的解决方案。 Docopt是一个值得一看的外部库，它使用文档字符串作为输入的解析器。 Click也是外部库，并使用装饰器定义参数。(我的线人推荐:Why Click) python-inquirer用于选择工具，并基于inquiry .js (repo)

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