Python 2.7のドキュメントには、さらに別のコマンドライン解析モジュールが含まれていることに気付きました。に加えてgetopt
、optparse
今持っていargparse
ます。
なぜさらに別のコマンドライン解析モジュールが作成されたのですか?代わりにそれを使用する必要があるのはなぜoptparse
ですか?知っておくべき新機能はありますか?
Python 2.7のドキュメントには、さらに別のコマンドライン解析モジュールが含まれていることに気付きました。に加えてgetopt
、optparse
今持っていargparse
ます。
なぜさらに別のコマンドライン解析モジュールが作成されたのですか?代わりにそれを使用する必要があるのはなぜoptparse
ですか?知っておくべき新機能はありますか?
回答:
pythonの時点で2.7
、optparse
は非推奨であり、将来的にはなくなる予定です。
argparse
元のページ(https://code.google.com/archive/p/argparse/)にリストされているすべての理由により、より優れています:
+
およびのような代替オプションのプレフィックスを許可する/
optparse
PEP での「純度」の言及は、後で追加するのがいかに複雑であるかについての議論で、ロックと同じくらい柔軟に(不十分に)コード化されているように聞こえます。
なぜoptparseの代わりにそれを使うべきなのですか?私が知っておくべき新機能はありますか?
@Nicholasの回答はこれをうまくカバーしていると思いますが、あなたが最初から始める「メタ」質問はそうではありません。
なぜさらに別のコマンドライン解析モジュールが作成されたのですか?
これは、便利なモジュールが標準ライブラリに追加されたときの最大のジレンマです。同じ種類の機能を提供するための大幅に優れているが、下位互換性のない方法が出現した場合はどうしますか?
古い、そして確かに卓越した方法に固執する(通常、複雑なパッケージについて話しているとき:asyncore対ツイスト、tkinter対wxまたはQtなど)または、同じことを実行するための複数の互換性のない方法になってしまう(XMLパーサーであるIMHOは、コマンドラインパーサーよりもさらに良い例ですが、 email
パッケージと同様の問題に対処するための無数の古い方法はそれほど遠くないわけではありません;-)。
古い方法が「非推奨」であることをドキュメントで脅迫するかもしれませんが、(下位互換性を維持する必要がある限り)大きくて重要なアプリケーションを新しいPythonリリースに移行することを止めずに、それらを取り除くことはできません。
(ジレンマ2は、あなたの質問に直接関係していませんが、「標準ライブラリは良いパッケージが死ぬところです」という古い言い回しに要約されています...毎年1年半ほどのリリースで、それほどではないパッケージ、非常に安定した、ではない)任意のより頻繁にそれより前のリリースを必要とし、実際には標準ライブラリに「凍結」であることによって、実質的に苦しむことができます...しかし、実際には別の問題だという。
parser.add_argument('--long-opt', '-l',...)
ます。「-」は簡単に処理できますが、好きなように操作できます。
:Pythonの追加の理論的根拠のための最高のソースはそのPEPなりPEP 389:argparse -新しいコマンドライン解析モジュール、特に、セクションと題する、なぜのgetoptとoptparseは十分なされていませんか?
ブロックには新しい子供たちもいます!
より詳細な比較が必要な場合は、こちらをお読みください。docoptを使用するか、をクリックしてください。カイル・パードンに感謝!
最初は、@ fmarkのようにoptparseからargparseに切り替えるのをためらっていました。
次に、このドキュメントを見たところ、argparseはoptparseよりも優れており、特に意味のあるヘルプメッセージの生成について話しているときは、http://argparse.googlecode.com/svn/trunk/doc/argparse-vs-optparse.html
そして、@ Nicholasによる" argparse vs. optparse " を見て、Python 2.7未満でargparseを利用できるようにした(そうですね、以前は知りませんでした)。
今、私の2つの懸念は十分に対処されています。私はそれが同様の考え方を持つ他の人を助けることを願ってこれを書きました。