Async refactoring: reduce code duplication
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
調査の方向性
Start by reviewing load_by_multiget() and the other methods that perform I/O; the issue does not name specific files or tests. Identify their preparation, API-call, and result-processing steps, and check the relevant type hints. Done means I/O methods signal possible coroutine returns and async refactoring reduces duplicated common logic without generated code.
索引モデルが issue の本文から書いたものです。
説明
I do want a library that can be used both with sync and async users, with as little code duplication as possible, and without generated code. Perhaps it was silly, perhaps "async first, autogenerated sync code" is the best solution. Anyway, Claude claimed that the "Sans-IO" design pattern would work well. Problem is that the library absolutely wasn't made Sans-IO in the first place.
We should think throughly on how to make version 4.0 more "sans-io". It's probably worth a separate ticket on "long term sans-io plans".. Right now I'm mostly concerned with "make it possible to use the library in an async way" and "refactor to reduce code duplication", and I think this is the way to go:
- All methods doing I/O should be identified. The type hints should be updated to indicate that those methods may return an async coroutine.
- Methods that first prepares something, then fires off some API call, and then processes the results should be refactored - the common code should not be duplicated. I've dealt with this some places (i.e.
load_by_multiget()) by first doing the preparation, thenif self.is_async_client: return self._async_load_by_multiget(xxx)and finallyself._post_load_by_multiget(xxx)for post-processing.
Is this refactoring sane? Any suggestions on how to do it more properly is welcome.
- 主要言語
- Python
- スター
- 412
- フォーク
- 113
- 平均マージ
- 2日 18時間
- マージ済み PR（30日）
- 15
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
python-caldav/caldav のほかの issue
-
Todo.complete(rrule_mode="this_and_future") raises AttributeError; only the undeclared "thisandfuture" works対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
python-caldav/caldav#735 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
python-caldav/caldav#687 ·
メンテナーはふだん 1 日以内に返信
-
iCloud: URL.join raises "can't be joined" when REPORT hrefs use caldav.icloud.com after client.url was rewritten to the pNN partition host対応中かも @tobixen が今日担当しました。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 52/100
python-caldav/caldav#730 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
python-caldav/caldav#725 ·
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 48/100
python-caldav/caldav#720 ·
メンテナーはふだん 1 日以内に返信
python-caldav/caldav の issue をすべて見る
似ている issue
-
request-theme
難易度 2/5 1時間未満 初心者へのやさしさ 70/100
LizardByte/ThemerrDB#8877 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
area/install-update comp/gateway P0 sweeper:risk-compatibility type/bug
難易度 2/5 1時間未満 初心者へのやさしさ 72/100
NousResearch/hermes-agent#135997 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
deepset-ai/haystack#13199 ·
メンテナーはふだん 1 日以内に返信
-
[BUG] JSONLoader rejects valid UTF-8 BOM files対応中かも @zouyonghe が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
anthropics/knowledge-work-plugins#1298 ·
メンテナーはふだん 1 日以内に返信