API設計：ストリームオブジェクトvs関数vsメッセージ
pythonライブラリのAPIを設計しています：さまざまな信号が入り、さまざまな信号が応答として生成されます（1対1の関係はありません）入力および出力信号）。
入力は、ネットワークソケット/ファイル/インタラクティブな（端末ベースの）ユーザー入力から取得できます。またはWebフレームワークのビュー関数から。同様に、出力をソケット/ファイル/画面に送信するか、呼び出し元に返す必要がある場合があります（この最後のケースでは、出力をバッファーに入れ、最後の呼び出し以降に蓄積されたすべての出力を返す必要があります）。異なるI/Oチャネルの選択は最初に一度行われ、プログラムの実行中は変更されません。
I/Oレイヤーが複数のスレッドまたはプロセスを使用しているか、非同期であると想定しています。そして、それは私のライブラリ関数を呼び出します。
引数として2つのストリームオブジェクト（入力と出力用）を受け入れることの長所と短所は何ですか。入力が利用可能または出力が必要なときに呼び出す必要がある関数を公開する。メッセージを使用して通信しますか？それとも、他のアプローチの方が良いですか？
簡単に：
messages：簡単なパラダイムであり、特に広範囲のI/O（tcp、http、ターミナルなど）をターゲットにする場合は、多くの場合、最も簡単にインターフェイスをとることができます。ほとんどの場合、I/Oストリームをキャッシュして処理するための独立した中間レイヤーがあります。
functions：まあ、それは同じ言語で使用されるライブラリに最適です。しかし、より高いレベルでそれとやり取りしたい場合は、とにかくその周りのラッパーが必要になります。
streams：libでストリームを直接受け入れることはメッセージに似ていますが、欠点があります。主に、ストリームで問題が発生する可能性に関するすべて（切断、タイムアウト、エラー...）は、個別のレイヤーではなく、「ビジネスロジック」での例外処理として終了する傾向があります。
私見、私はそれを「これかあれ」質問とは思わないでしょう。むしろ、この観点からそれを見るのは興味深いかもしれません。
ストリームは送信に使用されますメッセージ関数呼び出しの結果です