Skip to content

Conversation

@ayjayt
Copy link
Member

@ayjayt ayjayt commented Apr 25, 2025

Going to add audit comparison

ayjayt added 30 commits April 23, 2025 18:41
(english below)
Esta refactorización es tan grande que no tiene sentido mirar los
diffs de los commits.

Mejor mirar a los archivos nuevos, después del ultimo commit de
refactorización.

La idea es:

1. Unas funciones de laAPI de audit fueron quitadas, para hacer
   todo más sencillo.
2. Las funciones restantes están ya más sencillas porque:
   a) Son menos flexibles, no lidian con toda situación, solo
      la especificada.
   b) Se usa `@dataclass` para devoluciones (más en "Charla").
3. Con un mejor entendimiento de la organización requisito, una
   jerarquia more clara ha estado establecida. Pero, dada que estamos
  estancado en un solo archivo (`__init__`) en una sola clase, `GHApi`
  esa jerarchia encaja una clase en otras, todo en un archivo.
  Escapar el archivo sería buevo (v2?) pero se necesita más cambios.

Charla:

jq es muy expresivo en la transformación de datos pero también
devuelve dicts sin tipo. Pasando tales dicts entre capas se molesta
porque queda difícil limitar y entender el estado del objeto
en cualquier monento.

`TypedDict` tiene soluciones pero también desventajas.
1. No se puede usar `isinstance()`
2. No se puede tener métodos.

La ventaja es que se puede traver con `items()` cuando se necesita
todos los atributos/claves.

`@dataclass` es mejor dado que no tiene las desventajas dichas.
También `fields()`, parecido a`keys()`.

`@dataclass` también tiene `asdict(...)`, pero se copia. Se usa con
`tabulate()`, de forma automatica.

Pero, al aceso es diferente. `.clave` en vez de `[clave]`. Los
diccionarios tienen unas ventajas pero todavía necesitan más
herramientas, talvez glom.

ENGLISH

This refactor is so big it doesn't make sense to look at the diffs
of the commits.

It makes sense to simply to look at the new files, after the end-of-
refactor commit.

The basic idea is here:

1. Audit functions we're removed to simplify.
2. Existing functions were made more simple by
   a) being less flexible (not looking for all possible situations,
   but whatever is specified).
   b) using `@dataclass` for types returned (see discussion).
3. With a better understanding of the organization required, a more
  clear hierarchy has been established. However, since we're locked
  into a single file, in a single class, that hierarchy involves
  classes embedded in classes, everything in one file. Breaking
  out of one file and splitting the API into multiple files (as
  described for version two), would be good, but would require a
  restructuring.

Discussion:

jq is very expressive in transforming data but it also returns
typeless dicts. Passing typeless dicts between layers is annoying
because it's difficult to constrain and understand the state of
any single return.

`TypedDict` presented a solution but it has some problems:
1. it can't be used in `isinstance()`
2. it can't have methods

Its advantages is that it can be traversed with `items()` in the
case that an operation needs to be performed on every members.

`@dataclass` is a little bit better because it doesn't have the above
two drawbacks. It also has `fields()` which is like `keys()`.

`@dataclass` also has `asdict(...)` but that creates a copy.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants