Python 2.7ドキュメントには、さらに別のコマンドライン解析モジュールが含まれていることに気付きました。 getopt
とoptparse
に加えて、現在argparse
があります。
なぜ別のコマンドライン解析モジュールが作成されたのですか? optparse
の代わりに使用する必要があるのはなぜですか?知っておくべき新機能はありますか?
python 2.7
の時点で、 optparse
は非推奨であり、将来的には廃止される予定です。
argparse
は、元のページにリストされているすべての理由により優れています( https://code.google.com/archive/p/argparse/ ):
+
や/
などの代替オプションプレフィックスを許可する詳細情報は PEP 389 にもあります。これは、argparse
が標準ライブラリに入れた手段です。
Optparseの代わりに使用する必要があるのはなぜですか?知っておくべき新機能はありますか?
@Nicholasの答えはこれをうまくカバーしていると思いますが、あなたが始めた「メタ」な質問ではありません。
なぜ別のコマンドライン解析モジュールが作成されたのですか?
有用なモジュールが標準ライブラリに追加されたとき、それはジレンマのナンバーワンです。同じ種類の機能を提供するための大幅に改善された、しかし後方互換性のない方法が現れたらどうしますか?
古くて明らかに認められている方法に固執するか(通常、複雑なパッケージについて話している場合:asyncore vs twisted、tkinter vs wxまたはQt、...)、または同じことを行うための複数の互換性のない方法になります(XMLパーサー、IMHOは、コマンドラインパーサーよりもこの良い例です。しかし、email
パッケージと同様の問題に対処する無数の古い方法もそれほど遠くありません;-)。
「非推奨」である古い方法についてドキュメントで脅迫的な不平を言うかもしれませんが、(後方互換性を維持する必要がある限り)大きくて重要なアプリケーションが新しいPythonリリース。
(あなたの質問に直接関係しないジレンマ2は、「標準ライブラリは良いパッケージが死ぬ場所である」という古い言葉に要約されています...毎年リリースされており、そうではないパッケージ、 非常に安定、ではないそれよりも頻繁にリリースが必要で、実際には標準ライブラリで「フリーズ」されることで実質的に苦しむ可能性があります...しかし、それは本当に別の問題です) 。
Python追加の理論的根拠の最良のソースは、そのPEPです。 PEP 389:argparse-新しいコマンドライン解析モジュール 、特に、 というタイトルのセクションは、なぜgetoptとoptparseが十分ではないのですか?
ブロックには新しい子供もいます!
さらに詳細な比較が必要な場合は、 this をお読みください。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つの懸念は十分に解決されました。私はこれが同じような考え方を持つ他の人を助けることを期待して書いた。