Forem: Johnnatan Sandoval Cardona

Algo más de azúcar para python

Johnnatan Sandoval Cardona — Tue, 29 Oct 2024 15:34:23 +0000

Python 3.12 introdujo algo de azúcar sintáctica para definir clases y funciones genéricas. Veamos cómo funciona:

def max[T](args: Iterable[T]) -> T:
    ...

class list[T]:
    def __getitem__(self, index: int, /) -> T:
        ...

    def append(self, element: T) -> None:
        ...

Se agradece esta simplificación que es útil en definiciones simples.

También es ahora permitido crear aliases con type, aunque aún no he tenido la oportunidad de usarlo. El proyecto en el que trabajo en este momento usa python 3.10.

type Point = tuple[float, float]
type Point[T] = tuple[T, T]

Eligiendo la versión por defecto de node con nvm

Johnnatan Sandoval Cardona — Mon, 28 Oct 2024 21:25:09 +0000

Para manejar las diferentes versiones de node uso nvm. Al abrir una nueva terminal, la versión instalada se reinicia, lo que me obliga a ejecutar nvm use <version> continuamente.

Para definir una versión por defecto, podemos ejecutar:

nvm alias default v18.16.0

De esa forma, toda nueva terminal tendrá por defecto, la versión elegida.

La dificultad de las revisiones de código

Johnnatan Sandoval Cardona — Sat, 26 Oct 2024 16:30:58 +0000

Las revisiones de código son difíciles. No obstante, en la mayoría de empresas en las que he estado, no se hacen bien.

¿Qué dificultad posee una revisión de código? Que no es simplemente un problema técnico. Implica relaciones entre seres humanos. Por lo que he visto, algunos temen "herir" susceptibilidades al hacer un comentario, o se sienten mal frente a ciertas críticas al código. Claro está, hay maneras de decir las cosas; no obstante, deberíamos intentar ver las revisiones como un esfuerzo colectivo por mejorar, no como algo personal.

En varias empresas he visto que se sacrifica la calidad por no hacer sentir mal a los otros. Y eso también hace que las revisiones sean superficiales. La persona que revisa no piensa realmente el código; solo da una mirada general.

Por otro lado, está el problema de los estilos de programar. Como individuos, y siendo la programación una cuestión creativa, en parte, hay estilos. ¿Cómo separar lo que es realmente una necesidad, de una preferencia personal? Las diferencias en gustos y en experiencia hace difícil la comunicación al realizar una revisión de código. Por ejemplo: ¿abstraer o no abstraer? Me encuentro muchas veces con sugerencias de abstracciones que, desde mi punto de vista, son innecesarias. Soy más de abstraer cuando he logrado captar la esencia del problema. Para ello, necesito más de un caso. Prefiero dejar pasar algunos casos no generalizados, y no hacer una abstracción apresurada. No obstante, alguien con más experiencia, tanto en programar, como en conocimiento de un código, puede ver patrones que uno no puede ver. Tal vez tenga razón en sugerir un patrón (aunque, también, podría equivocarse porque, aceptémoslo, todos nos equivocamos).

En mi actual empresa, me he encontrado con revisiones de código bastante estrictas. En ocasiones, tienen razón con una sugerencia, en otras, no estoy seguro de si tenga sentido, o si de verdad sea una razón para bloquear la aprobación. Lo cierto es que tardo entre una y dos semanas en que mi código se apruebe, teniendo en cuenta que quienes revisan hacen una revisión diaria, en promedio. Siento que estoy yendo demasiado despacio. Sé que llevo apenas unos pocos meses, y he tenido que lidiar con cinco bases de código de servicios diferentes, y con personas diferentes, sin tener conocimiento profundo de cada uno, ni de las interacciones entre ellos. Más me gustaría acelerar todo. Reducir la probabilidad de recibir comentarios.

Con esto último, pasa que programamos pensando en el comentario que hará el otro, así no estemos totalmente de acuerdo con él. Haré esto así porque no quiero que me retrasen el código. ¿Es esto correcto? Es difícil. Las revisiones de código resultan ser un problema muy humano y no meramente técnico, como nos gustaría.

El módulo decimal de python

Johnnatan Sandoval Cardona — Wed, 25 Sep 2024 21:42:21 +0000

Los lenguajes de programación tienen diversos tipos de datos para manejar información numérica. El tipo entero (int), real (float) y python soporta otros como fracciones y complejos.

Hoy, sin embargo, quiero hablar del tipo decimal. Los float o de coma flotante, tiene varios problemas de precisión que no pueden tolerarse en ciertos tipos de aplicaciones como, por ejemplo, las que tienen que ver con finanzas.

Veamos un caso muy simple:

from decimal import Decimal

1.0 == 0.999999999999999999  # True
Decimal("1.0") == Decimal("0.999999999999999999") # False

Extendiendo sobre la clase decimal, existe el módulo py-money que adiciona a los números una moneda como USD o COP, permitiendo a las aplicaciones que así lo requieren, tener una precisión tan alta como se quiera.

Claro está que no es posible tener una precisión infinita en una computadora. Sin embargo, el módulo decimal se puede ajustar a una precisión tan grande como se necesite:

print(getcontext().prec)  # outpus 28 by default

Usé bastante el módulo decimal y también la librería py-money en un momento en que trabajaba en una aplicación financiera. Es correctamente soportada por django y otros frameworks.

Conociendo uv

Johnnatan Sandoval Cardona — Mon, 23 Sep 2024 01:40:11 +0000

uv es el nuevo administrador de proyectos escrito en Rust para python. ¿Por qué una nueva alternativa, habiendo tantas disponibles? Hace mucho empecé a usar pipenv, el cual eventualmente se volvió inútil. Luego migré a poetry que, además, usa mi empresa actual. Es una mejora, más no me termina de convencer.

Y es que no hay una solución definitiva en python a lo que quiere lograr uv. Un cargo para python.

poetry no es un reemplazo de pypenv. Por lo tanto, hay que seguir usando otras herramientas. Además, no es transparente.

He empezado a experimentar con uv y puedo decir que ya puedo reemplazar, cuando menos, pyenv. Tal vez podría usarlo en lugar de poetry; no obstante, en mi actual empresa usamos poetry y no creo que estemos listos para una migración.

¿Por qué creo que es una mejora? Con uv puedo ejecutar uv run mi-script.py y de manera automática utiliza un entorno virtual. No solo eso, puedo instalar paquetes para el archivo que son manejados dentro de comentarios. Por ejemplo: uv run --with rich example.py. Las dependencias y el entorno virtual se maneja de manera transparente.

No está de más decir que es extremadamente rápido. Muy por encima de las opciones. No por nada está hecho en rust lo que, a su vez, ofrece otra ventaja: no dependemos de una instalación previa de python, que puede ser problemática. uv es un binario que se instala y funciona sin problemas.

Empezaré a usarlo para manejar proyectos cada vez que pueda y como reemplazo de pip por lo que espero seguir escribiendo al respecto.

¿Desventajas? He visto comentarios que hablan de desconfianza hacia astral, la empresa detrás de uv y de cómo se financiarán. Igualmente, no les agrada del todo que se construya en rust y no en python, lo que puede ser una dificultad. Yo, por mi parte, pienso que no son razones suficientes. Por un lado, la comunidad ha sido incapaz de entregar una solución totalmente satisfactoria. Por el otro, es software libre, y, en caso de algún movimiento no deseado por parte de astral, se puede crear una bifurcación, aún si el costo de mantenimiento, en principio, es mayor por ser otro lenguaje.

Explorando org-babel en emacs

Johnnatan Sandoval Cardona — Sun, 15 Sep 2024 20:18:44 +0000

Soy usuario de GNU/Emacs desde el año 2005. A pesar de tanto tiempo, no me considero un experto. No me he querido meter de
lleno con ELisp, por ejemplo, así que las configuraciones que hago a emacs, las hago basándome en consejos de internet. Y, de un tiempo para acá, empecé a usar doom emacs, que me entrega una "distribución" pre-configurada y lista para usarse.

No obstante, cada tanto pruebo nuevas características que, aunque las
conozco desde hace mucho tiempo, no me había animado a usarlas. Una de
las más recientes es org-babel.

org-mode me permite introducir bloques de código por aquí y por allá. Es una forma de programación literata. Para ello, puedo definir bloques que empiezan con begin_src y terminan con end_src. Cualquier modo que emacs soporte, lo puedo definir de la siguiente
manera:

#+begin_src python
print("Hola mundo")
#+end_src

Al exportar, puedo obtener coloreado de sintaxis del lenguaje. No obstante, hay algo más que puedo hacer y es ejecutar el bloque de código con C-c C-c. Y lo puedo hacer con cualesquier lenguaje que org soporte, siempre que tenga acceso al intérprete.

Algo que he hecho en los últimos días, es almacenar instrucciones de la línea de comandos para pruebas que hago:

#+begin_src sh :results output>
http get https://google.com
#+end_src

De esa forma, puedo repetir continuamente un comando haciendo pequeñas modificaciones y ver la salida en el mismo buffer de emacs. Me gusta porque no soy muy fan de postman, y de esta forma no lo necesito. Puedo usar httpie o curl, donde me siento más cómodo.

Veamos el resultado de lo siguiente:

#+begin_src sh :results output
curl google.com
#+end_src

: <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
: <TITLE>301 Moved</TITLE></HEAD><BODY>
: <H1>301 Moved</H1>
: The document has moved
: <A HREF="http://www.google.com/">here</A>.
: </BODY></HTML>

Puedo copiar, puedo pegar o hacer lo que quiera. En este momento, no he probado la posibilidad de comunicar un bloque con otro, o de manejar sesiones. Tal vez lo haga más adelante. Por ahora, este es un paso más en emacs que me gusta.

Consideraciones en los serializadores del DRF

Johnnatan Sandoval Cardona — Thu, 05 Sep 2024 14:36:48 +0000

Django{.verbatim} es un gran framework para desarrollo web en
python. El django rest framework{.verbatim}, lo especializa para crear APIs REST{.verbatim} con mucha facilidad.

Django{.verbatim} tiene clases como modelo{.verbatim} y vista{.verbatim}, que corresponden, no de manera exacta, con los correspondientes del patrón modelo-vista-controlador.¹ El DRF agrega una clase nueva, los serializadores, encargados de transformar desde una representación, como json, a objetos de python y viceversa. Los serializadores son bastante flexibles y permiten incrustar en ellos lógica compleja de validación y de transformación de datos. No obstante, hacerlo es una mala idea, ya que podemos terminar con serializadores que implementan parte de la lógica del negocio o del dominio.

Este artículo no pretende hablar de ese problema, sino de otro que puede surgir con el abuso de los serializadores. Supongamos que tenemos una modelo llamado Company en nuestra aplicación. Los campos de este modelo/tabla poco nos importan. A su vez, tenemos varias vistas que deben lidiar con \"compañías\". Aparte de las típicas acciones de crear, listar, actualizar, traer o eliminar, otras clases podrían tener que lidiar de alguna forma con la clase compañía. Por ejemplo, por conveniencia, podríamos querer incrustar en los datos de un usuario, su compañía:

{
    "id": 1,
    "name": "Joseph",
    "company": {
        "id": 10
    }
}

Por tanto, crearemos uno o varios serializadores para lidiar con el
modelo Company. Es un patrón que he visto en varios proyectos el crear una clase padre llamada, por ejemplo, CompanySerializer, y de allí se desprenden clases específicas como CompanyUpdateSerializer o CompanyCreateSerializer en un intento de usar la herencia para
compartir funcionalidad aparentemente común.

No solo eso. Es muy probable que la vista de usuario que entrega la
compañía incrustada, decida compartir el mismo CompanySerializer en un intento de seguir el malentendido principio de no te repitas, o
Don\'t Repeat Yourself (DRY). Voy a justificar por qué esto es una
mala idea por varias razones.

Comencemos por argumentar en contra de la herencia. Existe otro
principio de diseño que nos sugiere preferir la composición por sobre la herencia. Es demasiado fácil y tentador abusar de la herencia como mecanismo de reutilización de código, lo que puede resultar en una aplicación mucho más difícil de entender. Lo explícito es mejor que lo implícito, y pocas cosas hay más implícitas que la herencia. Mi experiencia con el DRF{.verbatim} no ha hecho más que reafirmar en mi ese principio. Aunque parece intuitivo el que hayan diversos tipos de serializadores, lo cierto es que terminan siendo usados en contextos muy distintos. Especialmente cuando la aplicación crece, nos encontraremos con que habrá más lógica de negocio necesaria para crear, actualizar, e incluso para listar. Esa lógica es incompatible entre si, y termina siendo necesario hacer comprobaciones para saber en qué contexto se está llamando el serializador.

Dicho de otro modo, estamos violando el principio de única responsabilidad que dice que solo debe haber un motivo para que una clase cambie. Cuando una serializador es compartido en contextos tan diferentes, tiene múltiples razones para cambiar. Lo que sucede en un contexto, o caso de uso, puede afectar a otros contextos.

Desde otro punto de vista, nos damos cuenta que la clase CompanySerializer es referenciada por muchas otras clases en contextos diferentes. Eso es otra señal de un problema de diseño. Cuando de una clase dependen muchas otras (en términos visuales, a una clase entran muchas líneas), un cambio en esta puede afectar a sus dependientes.

Y es que no tiene sentido compartir serializadores. La apariencia de
reutilizar no es más que eso; algo superficial.

Pensemos en que la vista de usuario que incrusta la compañía, aunque en apariencia accede a la misma fila de la base de datos, puede tener menos (o más) permisos que las demás vistas que también la usan. Quiero decir que puede necesitar retornar menos campos por cuestión de privacidad y seguridad. ¿Cómo manejamos esto con un serializador compartido? Se vuelve complejo y es proponso a errores. Por ejemplo, una nueva característica puede querer acceder a una compañía con un dato que se considera privado en otros contextos. Lo agrega al serializador y, por arte de magia, ahora es accesible en todas las vistas que dependen de él. Esto, claro está, tiene solución, pero facilita demasiado el equivocarse.

¿Cuál es la solución? Simple, no reutilizar serializadores. Podemos
también decir: a cada vista le corresponde un único serializador. No importa que accedan al mismo dato, en apariencia. El contexto tan diferente hace que no sea, en el fondo, lo mismo.

Dado que es una relación única, podemos usar una estrategia de ubicar un serializador al interior de su vista. Así:

class CompanyView(APIView):
    class Serializer(ModelSerializer):
        ...

    def get(self, request):
        ...  # Podemos acceder al serializador haciendo: self.Serialzer

Es una opción, por supuesto, aunque es ideal para situaciones simples. ¿Qué pasa cuando el serializador posee serializadores anidados? Tal vez se haga complejo. Se puede resolver, pero, cuando menos, podemos siempre recurrir a la relación uno a uno ubicando los serializadores en el archivo serializer.py como es costumbre.

Notas

En django, una vista no corresponde con el concepto de vista en MVC. La combinación entre una plantilla (template) y una vista de django corresponde de mejor manera con la V de MVC. ¿Y los controladores? No hay tal cosa en django. Por esta razón se promueve la idea de vistas delgadas y modelos obesos. ↩

Descubriendo itertools

Johnnatan Sandoval Cardona — Tue, 03 Sep 2024 02:07:05 +0000

Itertools es una de las librerías más interesantes de python. Contiene una serie de funciones inspiradas en lenguajes funcionales que sirven para trabajar con iteradores.

En este artículo mencionaré alguna de las que más me han llamado la atención y que vale la pena tener presentes para no reinventar la rueda cada vez.

Count

Varias veces he implementado un conteo infinito (bueno, que termina
explícitamente en algún momento con un break) usando un ciclo while True. itertools nos ofrece una mejor alternativa:

    from itertools import count

    for i in count(start=2, step=2):
        if i > 10:
            break
        print(i)

Como puede verse en el ejemplo, de no ser por el break, count retornaría infinitos números. El código anterior es más o menos equivalente a:

    i = 2

    while True:
        if i > 10:
            break

        print(i)
        i += 2

batched

Una función para realizar algo muy común: obtener datos de una secuencia en lotes de tamaño n. Veamos un ejemplo:

from itertools import batched

    sequence = [1, 2, 3, 4, 5, 6, 7]

    for batch in batched(sequence, 2):  # lotes de tamaño 2
        print(batch)

    (1, 2)
    (3, 4)
    (5, 6)
    (7,)

Es de notar que el último lote puede ser de un tamaño menor o igual a n, como en este caso. Bastante útil, ¿no creen?

pairwise

Otra función sencilla y útil. Dada una secuencia (en realidad, dado un iterador), nos entrega sus elementos en pares.

Veámoslo mejor con un ejemplo:

from itertools import pairwise

    sequence = [1, 2, 3, 4, 5, 6, 7]

    for a, b in pairwise(sequence):
        print(a, b)

La cantidad de parejas es una menos que el tamaño de la secuencia de entrada.

product

Finalmente, para esta corta entrada, quiero hablar de product, una
implementación del producto cartesiano.

Útil para reemplazar un for anidado que recorra dos secuencia de datos:

from itertools import product

    A = [1, 2, 3]
    B = [5, 6, 7]

    for a, b in product(A, B):
        print(a, b)

Recibe un parámetro que nos permite realizar el producto cartesiano de una
secuencia consigo misma:

   from itertools import product

    A = [1, 2, 3]

    for a1, a2, a3 in product(A, repeat=3):
        print(a1, a2, a3)

En una próxima entrada, mencionaré otras funciones más de este útil módulo de
librería estándar de python. Espero les sea de utilidad.