###
9 オプション間の衝突

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

    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` (デフォルトの設定)
  オプション間の衝突をプログラム上のエラーとみなし、 `OptionConflictError` を送出します。
`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

だけが残ります。