Posts

__add__ e __iadd__ definen dos comportamientos distintos para la adición en Python: uno crea un nuevo objeto, el otro modifica el existente. Esta distinción tiene consecuencias reales sobre los alias y las referencias compartidas, y sorprende incluso a desarrolladores experimentados. add: la adición que crea __add__ es invocada por el operador +. Debe retornar un nuevo objeto y dejar los operandos sin cambios. class Vector: def __init__(self, x, y): self.x = x self.y = y def __add__(self, other): return Vector(self.x + other.x, self.y + other.y) a = Vector(1, 2) b = Vector(3, 4) c = a + b # nuevo Vector(4, 6) print(a.x, a.y) # 1 2 — a no cambia print(id(a) == id(c)) # False — objetos distintos a + b llama a a.__add__(b). Si __add__ no está definido en a o retorna NotImplemented, Python intenta b.__radd__(a). ...

Una comparación == sobre un token parece inofensiva. En la práctica, filtra información medible: el tiempo de ejecución varía según cuántos caracteres coinciden. Ese es el principio de una timing attack, y basta para que un atacante reconstruya el token carácter a carácter. El problema: la comparación que se detiene demasiado pronto Python compara cadenas carácter a carácter y se detiene en cuanto encuentra una diferencia. def verify_token(request): user_token = request.GET.get('token') valid_token = "secret_abc123" if user_token == valid_token: return JsonResponse({'access': 'granted'}) return JsonResponse({'access': 'denied'}) En la práctica: ...

El instinto ante un endpoint de reporting lento suele ser el cache. Un @cache_page, un cache.set(), y el problema parece desaparecer hasta la próxima expiración. Este enfoque tiene una limitación estructural que las vistas materializadas PostgreSQL resuelven desde la raíz. El problema del cache en los endpoints analíticos El cache Django almacena el resultado de una vista Python. La consulta SQL costosa se ejecuta igualmente en cada expiración del cache. Para un informe construido sobre múltiples JOINs y agregaciones, eso significa que el primer usuario tras cada cache miss espera varios segundos. ...

Acceder a r.width y escribir r.width = 15 con la misma sintaxis que un atributo normal, mientras se ejecuta validación o cálculo por debajo: eso es lo que @property aporta. Y cuando esa lógica necesita compartirse entre varias clases, los descriptores entran en juego. @property: getters y setters sin fricción @property permite exponer un atributo calculado o validado con la misma sintaxis que un atributo simple. class Rectangle: def __init__(self, width: float, height: float): self._width = width self._height = height @property def width(self) -> float: return self._width @width.setter def width(self, value: float) -> None: if value <= 0: raise ValueError("El ancho debe ser positivo.") self._width = value @property def area(self) -> float: return self._width * self._height El beneficio concreto: la API pública no cambia. Añadir validación a un atributo existente no rompe ningún código llamador. @property sin setter crea un atributo de solo lectura. @nombre.deleter gestiona la eliminación con del. ...

El acoplamiento se trata a menudo como una noción vaga: “está demasiado acoplado” no dice nada sobre qué cambiar concretamente. La connascencia proporciona un vocabulario preciso para nombrar las diferentes formas de acoplamiento, compararlas y decidir cuáles reducir primero. El concepto está documentado en detalle en connascence.io. Tres ejes para evaluar la connascencia Cada instancia de connascencia se analiza según tres ejes: Fuerza: cuanto más fuerte es la connascencia, más difícil es detectarla y refactorizarla. Grado: una entidad acoplada a cientos de otras es más problemática que una acoplada a dos. Localidad: dos componentes cercanos (misma clase, mismo módulo) pueden tolerar formas más fuertes. A distancia, esas mismas formas se vuelven peligrosas. Los 9 tipos de connascencia Connascencia de Nombre (CoN) Varios componentes se ponen de acuerdo sobre el nombre de una entidad. Es la forma más débil e inevitable. ...

Por defecto, Django carga todos los campos de un modelo en cada consulta. En una vista de lista con 50 artículos, eso significa obtener el contenido completo, el resumen, los metadatos y los campos de traducción 50 veces, aunque solo se muestre el título y la fecha. Cuatro métodos QuerySet de Django permiten controlar exactamente qué se carga: defer(), only(), values_list() y Prefetch(). El resultado: 2 consultas SQL en lugar de N+2, con únicamente las columnas necesarias. ...

Después de algunos meses de desarrollo, no es raro acumular 30, 50 o incluso 100 archivos de migración en una aplicación Django. Cada ejecución de tests que parte de una base vacía los reproduce todos. Cada despliegue en un entorno nuevo también. squashmigrations permite fusionar varias migraciones en una sola, sin perder la compatibilidad con los entornos que ya han aplicado migraciones anteriores. El comando y lo que genera La sintaxis acepta un rango de migraciones: ...

Dos peticiones simultáneas leen el stock de un producto, las dos ven que queda una unidad, y las dos confirman el pedido. El stock baja a -1. Este tipo de condición de carrera es casi imposible de reproducir en desarrollo y devastador en producción. select_for_update() es la respuesta de Django: adquirir un bloqueo SQL en el momento de la lectura para garantizar que ninguna otra transacción pueda modificar la fila antes de que termine la operación actual. ...

Por defecto, Python asigna un diccionario __dict__ a cada instancia de una clase. Es flexible, sí. Pero cuando se tienen miles o millones de objetos en memoria al mismo tiempo, ese coste se acumula rápidamente. __slots__ elimina ese diccionario y reemplaza el almacenamiento por instancia con descriptores internos más compactos. Resultado típico: entre un 40 y un 60 por ciento menos de memoria por instancia. Lo que hace Python sin slots Sin ninguna declaración especial, cada instancia lleva su propio __dict__: ...

Cuando se exponen datos desde un modelo Django hacia una API o un serializer, los nombres de los campos del modelo no siempre coinciden con lo que se quiere devolver. El enfoque habitual: recuperar las instancias y renombrar en Python. Existe una opción mejor: dejar que la base de datos haga el trabajo usando F() dentro de values(). El problema: los nombres de campo del modelo se imponen class Task(models.Model): name = models.CharField(...) created_at = models.DateTimeField(...) Si queremos devolver nombre_tarea en lugar de name, lo habitual es recuperar los datos y renombrar en Python, ya sea con una comprensión de diccionario o dentro del serializer. En cualquier caso, la transformación ocurre a posteriori, en memoria. ...