問題タブ [contextmanager]

最近、Python の with ステートメントで奇妙な動作に遭遇しました。__exit__Python のコンテキスト マネージャーを使用してメソッドの構成変更をロールバックするコードがあります。manager は、return Falseの finally ブロックに値を持っていました__exit__。次のコードでケースを分離しました - 唯一の違いは return ステートメントのインデントにあります:

上記のコードでは、ロールバックは例外で失敗します。私の質問は、なぜManager1が とは異なる動作をするかということですManager2。例外は with-statement の外側ではスローされずManager1、なぜ の終了時に例外がスローされるのかManager2。

のドキュメントに__exit__よると：

例外が提供され、メソッドが例外を抑制したい場合 (つまり、例外が伝播されないようにしたい場合)、真の値を返す必要があります。それ以外の場合、例外はこのメソッドの終了時に通常どおり処理されます。

私の意見では、どちらの場合も出口は True を返さないため、両方の場合で例外を抑制すべきではありません。ただし、Manager1 ではそうです。誰もそれを説明できますか？

Python 2.7.6 を使用しています。

次のコードを検討してください。

例の出力:

エラーが発生しました: ('Foo', 'Bar')

エラーが発生しました: ('Foo', 'Bar')

エラーが発生しました: ('Foo', 'Bar')

ネストされたステートメントがいくつwithかあり、コードのどこかで例外が発生した場合を処理したいと考えています。私が達成したいのは、実行が停止されることです（上記の例では「発生しないはずです」という出力はありません）が、エラー情報は一度だけ出力されます。したがって、同じエラーが既に処理されているかどうかを何らかの形で知る必要があります。

これをどのように達成できるか考えていますか?

別のコンテキストマネージャー内で作成されたコンテキストマネージャーは、Python でどのように処理する必要がありますか?

例:コンテキスト マネージャーとして機能するクラスと、コンテキスト マネージャーとしても機能するAクラスBがあるとします。ただし、クラスBインスタンスはインスタンス化して、クラスのインスタンスを使用する必要がありますA。私は PEP 343 を経験しましたが、これが私が考えた解決策です:

これは正しいアプローチですか？それとも、いくつかの落とし穴がありませんか？

私は最近、開いているファイルのシーケンスを返すメソッドを書きました。つまり、次のようなものです。

構文的には、次のようなことを行った場合、結果のオブジェクトを閉じる必要はないと思います。

その結果、_iterdirコンテキスト マネージャーでラップすることにしました。

これは正しく機能しているようです。

私が興味を持っているのは、これを行うことが良い習慣であるかどうかです。このパターンに従って問題が発生することはありますか (おそらく例外がスローされた場合)?

itertools.izip()複数のファイルの行を反復するために使用したいと思います。で使用するとすべてのファイルが確実に閉じられるように、コンテキスト マネージャー タイプを作成しましたwith。これはうまくいくようです：

2 つの質問:

1. これを正しく実装しましたか？
2. これをテストして、ファイルが閉じられていることを確認できますか、それとも信頼できますか?

が呼び出されたときに通知するために print ステートメントを使用しまし__exit__たが、これで十分なテストでしょうか?

multiprocessing.Poolオブジェクトを使用していて、コンストラクターの設定initializerを使用して、グローバル名前空間にリソースを作成する初期化関数を渡しているとします。リソースにコンテキスト マネージャーがあるとします。コンテキスト管理されたリソースがプロセスの存続期間中存続する必要があるが、最後に適切にクリーンアップされる場合、コンテキスト管理リソースのライフサイクルをどのように処理しますか?

これまでのところ、次のようなものがあります。

これ以降、プール プロセスはリソースを使用できます。ここまでは順調ですね。ただし、このクラスはor引数multiprocessing.Poolを提供しないため、クリーンアップの処理は少しトリッキーです。destructordeinitializer

私のアイデアの 1 つは、atexitモジュールを使用し、初期化子にクリーンアップを登録することです。このようなもの：

これは良いアプローチですか？これを行う簡単な方法はありますか？

EDIT：atexit動作していないようです。少なくとも私が上記で使用している方法ではないので、現時点ではまだこの問題の解決策がありません.

ブロック__enter__全体を でラップせずに、コンテキストマネージャーのメソッドで例外をキャッチする方法はありますか?withtry

それ自体で例外をキャッチできることはわかっていますが、ステートメント__enter__()を含む関数からそのエラーにアクセスできますか?with

表面的には、コンテキストマネージャーで例外をキャッチ__enter__()するという質問は同じように見えますが、実際には、ステートメントが囲むブロックとは異なる方法でコードを処理することではなく、確実__exit__に呼び出されるようにすることに関する質問です。__enter__with

...明らかに、動機はより明確になるはずです。ステートメントは、完全に自動化されたプロセスのwithログを設定しています。ロギングが設定される前にプログラムが失敗した場合、ロギングによる通知に頼ることができないため、何か特別なことをしなければなりません。そして、次のように、インデントを追加せずに効果を達成したいと思います。

try2 つのブロックを使用することのもう 1 つの欠点は、例外を処理__enter__するコードが、ブロックの後続の本体で例外を処理するコードの後に​​来ることwithです。