0

プロジェクトはPython 3ライブラリ(パッケージ)で、カスタムストリームバイナリプロトコルを実装しています。ストリーム処理クラスのペアを考える:Python 3:プロジェクトでコードを再利用する最良の方法。古典+非同期の両方のインタフェースをユーザに公開する必要がある場合

MyEncodingWriter(dst_stream) - 生のバイトストリーム MyDecodingReader(src_stream)にPythonオブジェクトを変換する - 私は、ブロッキング同期ストリームとasyncio StreamReader + StreamWriterの両方をサポートする必要があるメッセージに、生の符号化されたバイトを変換するか、Pythonは

オブジェクト、(おそらく、それらからサブクラス化)

私は理解しています私はcoroutines通常の同期機能として直接使用することはできません。

私はasyncioリーダ/ライタAPIの(read(), readexactly(),...) 私のクラスMyEncodingWriter()MyDecodingReader()中を模倣することだと思うので、唯一の違いは、非同期/ asyncioバージョンのキーワードを待つ余分になります。

私には2つのコピーがありますが、再利用できない非常に似たコードのreposがあります。

今のところ、私はこのアイデアしか持っていません... ...メタクラスの助けを借りて非同期(非同期/待機キーワードを取り除くことによって)から動的に同期コードを生成しようとしますか?

それはいくつかのより良いアプローチですか?

TYAには、このような二重実装の提案や美しいsampes/reposがあります。

答えて

0

ブロック版を非同期版のサブクラスにして呼び出しをラップします。テストされていない、おそらく構文エラーがありますが、これらの線に沿って:

class MyBlockingEncodingReader(MyEncodingReader): 
    def readexactly(self, n): 
     return asyncio.get_event_loop().run_until_complete(super().readexactly(n)) 
+0

オーバーヘッド期待されているが何を、私はそれが動作すると思います、ありがとう! 私は各コールのラップがいくつかの%を追加すると思います...あなたはそのようなオーバーヘッドの推測を持っていますか? – ppmag

+0

パーセンテージのオーバーヘッドで推測することは、実際には可能ではありません。それは多くのことに大きく依存しています(I/O自体が他のすべてのオーバーヘッドをほぼ確実に圧倒しています)。あなたはプロファイリングによってその質問に答えることができます。それを簡単に書いて、あなたのパフォーマンスの問題がどこにあるかを見て、それを最適化してください。単一の関数呼び出しの周りでマイクロ最適化を試みると、実際の利益のためにコードを混乱させるだけです。 (このコードが頻繁に呼び出されてボトルネックになる場合は、とにかくこの部分をCで書き直したいと思うかもしれません)。 –