为啥使用 argparse 而不是 optparse?
Posted
技术标签:
【中文标题】为啥使用 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 的包装器。 【参考方案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 我试图包含我的链接的摘要,我希望现在值得一个好的 *** 答案。【参考方案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
现在我的两个担忧得到了很好的解决。我写了这篇文章,希望它能帮助有类似心态的其他人。
【讨论】:
以上是关于为啥使用 argparse 而不是 optparse?的主要内容,如果未能解决你的问题,请参考以下文章
Python argparse:默认参数存储为字符串,而不是列表