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

Async refactoring: reduce code duplication

Abierto
  • ¿Algo no está bien?
#665 2 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
Refactorización
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
python
Área
backend

Línea de trabajo

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.

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

Descripción

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, then if self.is_async_client: return self._async_load_by_multiget(xxx) and finally self._post_load_by_multiget(xxx) for post-processing.

Is this refactoring sane? Any suggestions on how to do it more properly is welcome.

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

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.