Consider adding close_connections argument to serve
メンテナーはふだん 2 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
- issue の種類
- 機能追加
- 明瞭さ
- 説明が足りない
- 活発さ
- 活発
- 技術スタック
- python
- 領域
- api, backend, networking
調査の方向性
Start by comparing the asyncio, threading, and trio serve implementations with their close, shutdown, and aclose methods. Decide whether serve should gain close_connections, close_code, and close_reason or whether documentation should show the recommended pattern; done means the chosen behavior is consistently implemented or documented across all three implementations.
索引モデルが issue の本文から書いたものです。
説明
The close / shutdown / aclose methods of servers (in asyncio / threading / trio implementations) take a close_connections argument to control whether the server should close connections proactively (the default behavior) or wait for clients to disconnect by themselves (which could be arbitrarily long).
When using serve as a context manager, there is no way to control this behavior. An obvious option would consist in adding a close_connections argument to serve, then proxy it to close / shutdown / aclose in __aexit__ / __exit__ / __aexit__.
If we do this, for completeness, we should also add close_code and close_reason. This means adding three arguments to serve. I'm not convinced that it's a good trade-off.
An alternative would consist in documenting the recommended pattern for controlling this behavior. Currently, the trio implementation shows an example of using aclose which can easily be extended with some parameter. The asyncio and threading implementations don't show examples of using close and shutdown.
- 主要言語
- Python
- スター
- 5.7k
- フォーク
- 617
- 平均マージ
- 1日 14時間
- マージ済み PR（30日）
- 7
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
似ている issue
-
adr
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
kristofdegrave/homeassistant-smart-charging#1607 ·
メンテナーはふだん 1 日以内に返信
-
namespace operations
難易度 2/5 1〜3時間 初心者へのやさしさ 64/100
EclipseFdn/open-vsx.org#13665 ·
メンテナーはふだん 1 日以内に返信
-
doc good first issue help wanted
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
collective/icalendar#1865 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
canonical/opentelemetry-collector-operator#409 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
mozilla/addons-release-tests#1243 ·
メンテナーはふだん 1 日以内に返信