Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Sync mode support for the httpx family

Abierto
  • ¿Algo no está bien?
#696 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
32/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
python
Área
backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
412
Forks
113
Merge medio
1 d 6 h
PR fusionados (30 d)
35

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de python-caldav/caldav

Todos los issues de python-caldav/caldav

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.