6.21.3.6 オプション間の衝突

注意が足りないと、衝突するオプションを定義しやすくなります:

parser.add_option("-n", "--dry-run", ...)
[...]
parser.add_option("-n", "--noisy", ...)

(とりわけ、OptionParser から標準的なオプションを備えた自前のサブクラスを定義してしまった場合にはよく起きます。)

ユーザがオプションを追加するたびに、optparse は既存のオプションとの衝突がないかチェックします。何らかの衝突が見付かると、現在設定されている衝突処理メカニズムを呼び出します。衝突処理メカニズムはコンストラクタ中で呼び出せます:

parser = OptionParser(..., conflict_handler="...")

parser.set_conflict_handler("...")

一例として、衝突をインテリジェントに解決する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