注意が足りないと、衝突するオプションを定義しやすくなります:
parser.add_option("-n", "--dry-run", ...) [...] parser.add_option("-n", "--noisy", ...)
(とりわけ、OptionParser から標準的なオプションを備えた自前のサブクラスを 定義してしまった場合にはよく起きます。)
ユーザがオプションを追加するたびに、optparse は既存のオプションとの衝突 がないかチェックします。何らかの衝突が見付かると、現在設定されている衝突処理メカニズム を呼び出します。衝突処理メカニズムはコンストラクタ中で呼び出せます:
parser = OptionParser(..., conflict_handler=handler)
個別にも呼び出せます:
parser.set_conflict_handler(handler)
衝突時の処理をおこなうハンドラ(handler)には、以下のものが利用できます:
error
(デフォルトの設定)resolve
一例として、衝突をインテリジェントに解決するOptionParser を定義し、衝突を起こすようなオプションを追加してみましょう:
parser = OptionParser(conflict_handler="resolve") parser.add_option("-n", "--dry-run", ..., help="do no harm") parser.add_option("-n", "--noisy", ..., help="be noisy")
この時点で、optparse はすでに追加済のオプションが
オプション文字列 "-n"
を使っていることを検出します。
conflict_handler
が "resolve"
なので、
optparseは既に追加済のオプションリストの方から
"-n"
を除去して問題を解決します。従って、"-n"
の除去
されたオプションは"-dry-run"
だけでしか有効にできなく
なります。ユーザがヘルプ文字列を要求した場合、問題解決の結果を反映した
メッセージが出力されます:
options: --dry-run do no harm [...] -n, --noisy be noisy
これまでに追加したオプション文字列を跡形もなく削り去り、ユーザがそのオプションを コマンドラインから起動する手段をなくせます。 この場合、optparse はオプションを完全に除去してしまうので、 こうしたオプションはヘルプテキストやその他のどこにも表示されなくなります。 例えば、現在の OptionParser の場合、以下の操作:
parser.add_option("--dry-run", ..., help="new dry-run option")
を行った時点で、最初の -n/-dry-run オプションはもはやアクセスできなくなります。このため、optparse は オプションを消去してしまい、ヘルプテキスト:
options: [...] -n, --noisy be noisy --dry-run new dry-run option
だけが残ります。
ご意見やご指摘をお寄せになりたい方は、 このドキュメントについて... をご覧ください。