Sync mode support for the httpx family
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Read caldav/davclient.py alongside caldav/async_davclient.py to understand the sync client’s requests/niquests assumptions and the async client’s _USE_HTTPX handling. Check caldav/response.py for existing response compatibility; the issue leaves open whether to add a sync switch or design a shared transport layer. Done means the sync client can use the httpx family without requiring requests or niquests.
由索引模型根据 Issue 内容生成。
描述
We should support using httpx2 for sync-requests, it seems preferable to the old requests module. The text below is AI-generated.
Today the two clients accept different HTTP libraries:
- async (
caldav/async_davclient.py): niquests, then httpx2, then httpxyz,
then httpx - whichever imports first. - sync (
caldav/davclient.py): niquests, then requests. The httpx family is
not an option at all.
So a project that already depends on httpx, and uses caldav synchronously, has to
pull in requests or niquests purely for this library. That is the same argument
as https://github.com/python-caldav/caldav/issues/690 - a library should prefer
the HTTP stack its consumer already has, rather than adding one - and it was
raised in https://github.com/python-caldav/caldav/issues/611#issuecomment-5335287677:
Considering that, we should consider supporting httpx/httpx2 also for sync
operations. However, this will have to wait for 3.4 - at least.
Filing it so it does not get lost.
What is involved
The sync client is written against the requests API and niquests is a drop-in for
it, which is why that fallback was nearly free. httpx is not a drop-in:
requests.Session/niquests.Sessionvshttpx.Clientrequests.auth.AuthBasevshttpx.Auth- different contract, and
_HttpxBearerAuthalready exists in the async client for exactly thisresponse.reasonvsresponse.reason_phrase-caldav/response.pyalready
handles both- different exception hierarchies, which matters wherever the client catches
connection or timeout errors close()vsclose()is fine, but the context-manager semantics differ
The async client already carries most of these distinctions behind _USE_HTTPX;
the interesting question is whether the sync client should grow the same switch or
whether the two should share one thin transport layer. The latter is more work
and much better, and is probably a 4.0 conversation rather than a 3.4 one.
Not urgent
Nothing is broken; this is about not forcing a dependency on consumers who
already have one that would do.
- 主要语言
- Python
- 星标
- 412
- 派生
- 113
- 平均合并
- 22 小时 15 分钟
- 30 天内合并 PR
- 44
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
python-caldav/caldav 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
python-caldav/caldav#788 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
python-caldav/caldav#687 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 35/100
python-caldav/caldav#786 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 48/100
python-caldav/caldav#784 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 35/100
python-caldav/caldav#783 · 1 条评论 ·
维护者通常 1 天内回复
查看 python-caldav/caldav 的全部 Issue
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
-
Status: Triaged Type: Enhancement
难度 1/5 1 小时以内 新手友好度 82/100
canonical/craft-store#448 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 74/100
维护者通常 1 天内回复
-
good first issue research size:s skill:numerics sub-issue
难度 2/5 1-3 小时 新手友好度 78/100
SKaiNET-developers/SKaiNET#1372 ·
维护者通常 1 天内回复
-
debt
难度 2/5 1-3 小时 新手友好度 68/100
microsoft/vscode-flake8#601 ·
维护者通常 1 天内回复