Werkzeug: werkzeugはASGIをサポートする計画がありますか？

はい、WerkzeugとFlaskは最終的にASGIをサポートします。 私にはこれのタイムラインがありませんが、誰かがPRを開始した場合は、PRのレビューを喜んでお手伝いします。

ただし、それを実装するのは私ではありません。コミュニティの支援が必要です。 以下の最新の更新を参照してください： https ：//github.com/pallets/werkzeug/issues/1322#issuecomment -600926145

私はこれに取り組むことに興味があります。

私はいくつかの機能しているがハッキーなASGIサポートを行っています： werkzeug 、 flask 。 先に進む前に、あなたが持っているかもしれない計画についてもっと理解したいと思います。

私がそこで行ったことすべてが一般的にもっと良いかもしれないという事実を超えて、私にすでに起こっていること：

• スレッドで同期コードを実行するだけでフォームパーサーをサポートしています（データを非同期で読み取るときにブロックします）。 私はこれがうまくいくとは思わない。 私の好ましいアプローチは、IOを除外することです。
• コンテキストローカルサポートはかなり壊れやすいです。 これを行うには正しい方法があるようですが、それはグローバルな状態に干渉することを含み、特にASGIでは、私たちが世界を所有しているとは想定できません。
• ASGIで実行している場合、同期関数のフォームデータをオンデマンドで解析する明確な方法はありません。 ビュー関数が非同期であることがわからない限り、フォームデータを熱心に解析することを検討する価値があるかもしれません。 デフォルトが何であれ、それをオーバーライドするデコレータが明らかに存在する可能性があります。

感想を聞かせてください。

スレッドで同期コードを実行するだけでフォームパーサーをサポートしています（データを非同期で読み取るときにブロックします）。 私はこれがうまくいくとは思わない。 私の好ましいアプローチは、IOを除外することです。

軽いタッチのアプローチは、既存のパーサーを再実装することですが、非同期IOを使用することになると思います。 2つのパーサークラスが内部で共通のsans-IO実装を共有できればよりクリーンになりますが、既存の実装を複製してわずかに変更するだけの方が実用的かもしれません。

コンテキストローカルサポートはかなり壊れやすいです。

コンテキストローカル（asyncioの場合）は3.7stdlibに存在します。 https://docs.python.org/3.7/library/contextvars.html
以前のバージョンのPythonをサポートするために、オプションのcompatライブラリとともにそれらを使用すると思います。 （または、FlaskのASGIが3.7以上になると仮定します）

werkzeugはスレッドローカルを使用しますか？ （私はFlaskがそうすることを知っています）

ASGIで実行している場合、同期関数のフォームデータをオンデマンドで解析する明確な方法はありません。

フォームデータを解析するための同期インターフェイスを提供しないことをお勧めします。 （または、何らかの方法でリクエスト本文にアクセスするため）、代わりに非同期APIを提供します。 ここでいくつかの例についてはStarletteのAPIを参照してください... https：//github.com/encode/starlette#body

Python 3.7がリリースされたので、他のコードが影響を受けない限り、Python3.7を必要とする非同期機能を持つことに反対することはありません。 しかし、ネイティブ3.7ソリューションと同じくらい優れたバックポートがある場合はさらに優れています！

非同期フォームデータの解析について...非同期関数のawait request.parse()のようなもので十分だと思いますが、解析されていないフォームデータにアクセスしようとすると例外が発生しますか？

確かに、または単にvaluesと友達を非同期にします： values = await request.valuesまたはvalues = await request.values() 、主にどちらが見栄えが良いかによって異なります。

間に割り当てずに直接dict要素を取得しながら非同期呼び出しを行うには、 (await request.form)['foo']のようなかなり醜いものが必要ではないでしょうか。

はい ：（

しかし、それが特に回避できるかどうかはわかりません。 私は思わない

form = await request.form
form['foo']

本当に醜いです

await request.parse()
request.form['foo']

それは明らかに好みに左右されますが。

代わりに_members_がすべて非同期化された「asyncdict」を発明することもできると思いますが、それを見ていないと、かなり混乱してしまうと思います。

確かに、または単に値と友達を非同期にする：values = awaitrequest.valuesまたはvalues = await request.values（）、主にどちらが見栄えが良いかに依存します。

プロパティではなく、I / O実行操作に関数呼び出しを使用することをお勧めします。

（await request.form）['foo']のように、間に割り当てずに直接dict要素を取得しながら非同期呼び出しを行うには、かなり醜いものが必要ではないでしょうか。

肩をすくめる-そうしないでください。

asyncioは、コードベースのどの部分がI / Oを実行するかについて必然的により明確になるため、それらを別々の行に分割する傾向があります。

form = await request.form()
form['foo']

私は非同期サポートを追加することに全力を注いでいますが、Python2と同期バージョンを壊すことはできません。 @njsmithから聞いたアプローチの1つは、すべてを非同期として記述し、2to3と同様のツールを使用して同期バージョンを生成することです。 どうやらそれはurllib3で試されているようですが、私はそれについて十分に知りません。

request.formなどの背後にあるオブジェクトに魔法を追加できるのではないかと思います。そのため、オブジェクトを呼び出すと、通常のdictのようなメソッドが同期されている間に非同期処理が実行されます（非同期モードでは失敗します）。 または、非同期モードでrequest.formなどへのアクセスに失敗し、非同期バージョンに別の名前（ request.parse_form() $など）を使用することもできます。

または...誰かが非同期を望んでいる場合request_class = AsyncRequest 。 これは、実際にはAsyncFlaskクラスのデフォルトである可能性があります。

または... request_class = AsyncRequest（誰かが非同期を希望する場合）。 これは、実際にはAsyncFlaskクラスのデフォルトである可能性があります。

それは私にとって理にかなっているようなアプローチです、ええ。

フォームパーサーに関しては、＃1330でsansio-ingを試みました。

https://github.com/andrew-d/python-multipartには、100％カバレッジのストリーミングフォームパーサーの実装もあります。 （私はもう1つ見つけましたが、それが「データのフィード、イベントの処理」フローに簡単に適応できるかどうかは明らかではありませんでした。）

python-multipartは、現在Starletteに使用しているライブラリです。 ここで非同期ストリームとの統合を見ることができます： https ：//github.com/encode/starlette/blob/master/starlette/formparsers.py#L207

Starletteにも必要なので、同期および非同期互換のインターフェイスを提示するための最良の方法についても考えています（ただし、Werkzeugとは逆の方向に進んでいますが、私にとっては、「既存の非同期インターフェイスがあります。どうすればよいですか？同期のものも提示するようになりました」）

Starletteの場合、おそらく実際の解析をasync parse(self)メソッドにプッシュし、通常はリクエストのディスパッチ中にそれを呼び出しますが、通常のプレーンプロパティform 、 filesなどを公開します。 ...ユーザーコードからの結果にアクセスするため。

トピックから外れていますが、人気のあるASGIとwerkzeugのケースに関連しています（この問題を脱線させたくはありませんが、追加する内容のない重複した問題を作成したくありません）：

https://github.com/django-extensions/django-extensionsを./manage.py runserver_plusで実行していて、 https：//github.com/django/channels （ASGIを使用）がOpcode -1を提供している場合インスペクターで./manage.py runserverを実行してみてください。

（Werkzeugはdjango-extensionsを使用してDjangoの内部で使用されており、デバッグ用にrunserver_plusを使用して開発することに慣れているので、その理由を理解するために数時間を費やしました）

開発でhttpsを使用できるように、runserver_plusを使用しています。
現在、Djangoチャネルを使用してWebsocketサポートを追加しようとしていますが、チャネルがrunserverを使用し、runserver_plusをサポートしないという問題が発生しました。 したがって、チャネルを使用することも、httpsを使用することもできますが、両方を使用することはできません。

@davidismは、このトピックでの最後の回答以降、FlaskのASGIサポートの実装に変更があったかどうか、およびPython2のサポートを終了するためにこのタスクに関連して計画が変更されたかどうかを教えてください。

2018年7月2日、 @ davidismは次のように書いています。

どうやらそれはurllib3で試されているようですが、私はそれについて十分に知りません。

しばらく前からこれを見たばかりです。誰かがもっと学びたいと思っているなら、python-trio / urllib3＃1にはたくさんの詳細があるようです。 urllib3 / urllib3＃1323へのリンクに注意してください。これには次のものが含まれます。

解決策：コードの1つのコピー（async / awaitアノテーションが付いたバージョン）を維持してから、小さなスクリプトがそれらを自動的に削除することで同期コピーを維持します。 それは美しくはありませんが、私が知る限り、すべての選択肢はもっと悪いです...

（興味があればそこで読み続けてください。）

https://github.com/python-trio/urllib3/commits/bleach-spikeで着実に進展していることに基づいて、これがうまく機能し続けていることを確認できてうれしいです。

この問題をレーダーに戻すための小さなバンプ。 今年3.5がEOLに到達したので、非同期サポートについて考え始めるのに良い時期だと思いますか？

これが掲載されてから1年半の間、それを実装するための活動はあまりありませんでした。 個人的には非同期の経験も必要もありませんし、ASGIは好きですが、自分でやろうと思ったことは一度もありませんでした。

その間に、Quartの作者である@pgjonesは、Werkzeugにより深く関与するようになりました。 Quartは現在、可能な限り舞台裏でWerkzeugを使用しており、私たちはそれを開発し続けています。 ASGIを使用することについてFlaskのメンテナからの反発があったため、Philはパレット/ flask＃3412も作成しました。これにより、少なくともasync def関数へのルーティングが可能になりますが、それはしばらくの間続いています。 この時点で、私はそれを受け入れるよりもASGIに行きたいと思います。 @ edk0は、sans-ioを解析するフォームを作成するために＃1330を作成しましたが、それも座っているので、おそらく最初にもう少し設計とレビューを行う必要があります。

「なぜFlaskはDjangoがやったことをできないのですか？」と尋ねるかもしれません。 私はDjangoの内部の専門家ではありませんが、 @ andrewgodwinは少し前に、Djangoは元々WSGIに適応していたため、「より簡単な」（まだ非常に複雑な）時間があると説明しました。 WerkzeugとFlaskが始めた非常にWSGI中心のAPI。 また、Djangoは、パレットよりもはるかに多くのフルタイムの注目とリソースを獲得しています。

では、それはこの問題をどこに残すのでしょうか？ Werkzeugを使用するFlask互換のフレームワークが必要な場合は、Quartを使用してください。 Quart（またはFlask）に貢献して、不足しているAPIとの互換性を高めます。 WerkzeugとFlaskでASGIをサポートする場合は、ステップアップする必要があります。 ASGIについて学び始めます。 WerkzeugのAPIのWSGI固有のブロック部分の特定を開始します。 WSGIとASGIの両方の実装を可能にするために作成できる抽象化について考え始めます。 次に、その調査をこのディスカッションに戻し、PRの設計と作成を開始できるようにします。

クォートの提案をありがとう、私はそれに貢献を受け入れることを非常に嬉しく思います。

この記事でDjangoが行ったことをFlaskが実行できないと思う理由に答えようとしました。 最終的には、pallets / flask＃3412がFlaskの最良のソリューションだと思います。

Werkzeugに関しては、ASGIは可能だと思いますが、多少の苦痛はあります。 痛みの注目すべき例は、Werkzeugの多くのものがWSGI呼び出し可能オブジェクト（例外など）であるということです。 ASGIでは、この機能をどのように使用できるか、または使用する必要があるかが明確ではないため、削除したいと思います。

私の計画は、WerkzeugをQuartに統合し続け、WerkzeugをASGI（sans-io）に向けて調整することです（受け入れられる限り）-私の唯一の障害は時間の不足です。