Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Sync mode support for the httpx family

Aperta
  • Qualcosa non va?
#696 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
32/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
python
Ambito
backend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Python
Stelle
412
Fork
113
Merge medio
2g 18h
PR unite (30g)
15

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di python-caldav/caldav

Tutte le issue di python-caldav/caldav

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.