処理時に消費されるパケットのキューを時々蓄積する Receiver オブジェクトがあります。このレシーバーにイテレーター プロトコルを持たせることは合理的と思われるため、next( receiver )手動で次のパケットを取得for packet in receiverし、現在利用可能なパケットを反復処理します。直感的には、このような繰り返しを 1 回実行し、受信側が値forを上げてループを停止するまで利用可能なすべてのパケットを処理しStopIteration(これは、イテレーターがfor停止する時間をループに通知する標準的な方法です)、後でそのようなforもう一度ループして、その間に到着した新しいパケットを処理します。
ただし、Python のドキュメントには次のように書かれています。
イテレータの
__next__()メソッドが を発生させるStopIterationと、後続の呼び出しでも引き続き発生させる必要があります。このプロパティに従わない実装は壊れていると見なされます。
このコードはおそらく「壊れていると見なされる」と思われますが、私が知る限り、問題なく動作します。ですから、一見うまく機能しているように見え、イテレータが機能することを直感的に期待する方法でコードを作成することは、私にとってどれほど悪いことでしょうか? 調達した後にさらにアイテムを返すことについて、実際に壊れているものはありますStopIterationか? これを変更する必要がある理由はありますか？
(レシーバーをイテレーター自体 (独自のメソッドを持つ) ではなく、単なる反復可能(そのメソッドが他のイテレーターを生成する)にすることができることは認識していますが、(a) これは、おなじみの直感的な使用法をサポートしません。__iter____next__next( receiver )次のパケットをキューからポップする (b) 完全に問題のないイテレータのようなオブジェクトを既に持っている場合、新しいイテレータ オブジェクトを繰り返し生成するのは無駄で非効率的です。 c) レシーバーがパケットを取得するときにパケットを消費するため、レシーバーを一種の反復可能なコンテナーとして提示するのは誤解を招く可能性があります (私が Python ラッパーを作成している C ライブラリーに組み込まれた動作であり、私はそうは思いません)。 Python でもキャッシュを開始するのは理にかなっています)、したがって、誰かが複数のイテレータを作成して、受信者のキューを自分のペースでトラバースしようとした場合、イテレータは互いにアイテムを盗み、これを単一のストップ アンド ゴーイテレータとして提示することから生じる結果よりもはるかに紛らわしい結果をもたらします。反復可能なコンテナーとしてではなく)。