为什么使用argparse而不是optparse？
我注意到Python 2.7文档还包含另一个命令行parsing模块。 除了getopt和optparse之外，我们现在已经有了argparse 。
为什么还有另一个命令行parsing模块被创build？ 为什么我应该使用它而不是optparse ？ 是否有我应该知道的新function？
从python 2.7 ， optparse已经被弃用了，并且希望将来可以离开。
argparse更适合原始页面（ https://code.google.com/archive/p/argparse/ ）中列出的所有原因：
- 处理位置参数
- 支持子命令
- 允许替代选项前缀，如
+和/ - 处理零个或多个和一个或多个样式的参数
- 产生更多的信息使用信息
- 为自定义types和操作提供了更简单的界面
在PEP 389中也有更多的信息，这是把它作为标准库的工具。
为什么我应该使用它而不是optparse？ 他们的新function我应该知道吗？
@尼古拉斯的答案涵盖了这一点，我想，但不是更多的“元”的问题，你开始：
为什么还有另一个命令行parsing模块被创build？
当任何有用的模块被添加到标准库中时，这就是第一个难题：当提供相同types的function的更好，但是后向不兼容的方式出现时，你会做什么？
要么你坚持以前的和公认的超越的方式（通常当我们谈论复杂的软件包：asyncore vs twisted，tkinter vs wx或Qt，…），或者你最终以多种不兼容的方式来做同样的事情（XMLparsing器，恕我直言，比命令行parsing器是一个更好的例子 – 但email软件包与无数古老的方式来处理类似的问题也不是太遥远;-)。
您可能会在旧版本的文档中做出威胁性的唠叨，但是（只要您需要保持向后兼容性），如果不阻止大型重要应用程序停止迁移到较新的Python版本，则无法将其取消。
（第二个与您的问题没有直接关系的窘境，在老话说“标准图书馆是好的包装去死的地方”，每年一年半发布，包装不是很好， 非常稳定， 不需要经常发布，实际上可以通过在标准库中“冻结”而受到实质性的损害……但是，这确实是一个不同的问题）。
为Python添加理由的最佳来源是它的PEP： PEP 389：argparse – 新的命令行parsing模块 ，特别是标题为“ 为什么不getopt和optparse足够？
这个街区也有新的孩子！ 阅读这个 ，你可以使用docopt或点击
起初我和@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（是的，我以前不知道）。
现在我的两个顾虑很好解决。 我写这个希望能帮助其他人有相似的心态。
PEP 389有一节直接解决了这个问题 。
我个人更喜欢optparse而不是argparse，因为
-
argparse是它有一些有问题的行为，使得处理任意的命令行界面。
-
argparse已经内置了神奇的行为来猜测是否某个参数或选项。 当处理不完整的命令行时，这成为一个问题，因为如果没有完全理解命令行parsing器的行为，就不可能知道。
-
argparse目前不支持禁用散布的参数。
对于基本的命令行应用程序都可以正常工
