Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Sync mode support for the httpx family

Đang mở
  • Có gì không ổn?
#696 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
32/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
python
Lĩnh vực
backend

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

enhancement

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.Session vs httpx.Client
  • requests.auth.AuthBase vs httpx.Auth - different contract, and
    _HttpxBearerAuth already exists in the async client for exactly this
  • response.reason vs response.reason_phrase - caldav/response.py already
    handles both
  • different exception hierarchies, which matters wherever the client catches
    connection or timeout errors
  • close() vs close() 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.

Ngôn ngữ chính
Python
Star
412
Fork
113
Merge trung bình
22 giờ 43 phút
Pull request đã merge (30 ngày)
43

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của python-caldav/caldav

Tất cả issue của python-caldav/caldav

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.