Jupyter no es que sea vago, es que hace bien su trabajo

Hace un par de años, ya como Jefe de Desarrollo, me tocó meterme en un quilombo que no era mío pero terminó siéndolo: un equipo de data science necesitaba que su modelo de scoring pasara a producción, y todo — todo — vivía en un notebook de 4000 líneas con celdas ejecutadas en orden random, variables globales reutilizadas seis veces y un git log que mostraba diffs de binarios ilegibles cada vez que alguien tocaba una gráfica.

Mi primer instinto, con toda mi cultura de infraestructura y Linux a cuestas, fue putear contra el formato .ipynb. "¿Cómo hacen code review de esto? ¿Cómo mergeás esto sin llorar?" Pero después de un par de días laburando con esas personas entendí algo importante: el notebook no está ahí porque el data scientist sea vago o no sepa programar bien. Está ahí porque es la herramienta correcta para el trabajo que estaban haciendo — explorar, iterar, visualizar, repetir. Ese día aprendí a separar el problema de "cómo versionamos esto" del problema de "esta herramienta es mala". No lo es. Es brillante para lo que fue diseñada, y por eso aparece en tres awesome lists independientes sin que nadie se sorprenda.

Mi tesis, después de ese quilombo: el notebook no es el enemigo del versionado, es el síntoma de que estás tratando dos trabajos distintos (explorar y producir) como si fueran uno solo. El problema nunca fue Jupyter. Fue no tener el corte claro entre "acá pienso" y "acá despliego".

Qué hace

Jupyter Notebook es un entorno web interactivo que te deja mezclar código ejecutable, texto en Markdown, visualizaciones y outputs en un solo documento vivo. La arquitectura, por abajo, es más interesante de lo que parece: no es un editor de texto con un intérprete pegado. Es un cliente-servidor donde el navegador (el frontend) habla con un kernel — un proceso separado que ejecuta tu código — a través de un protocolo basado en ZeroMQ. Eso significa que podés tener el kernel corriendo en una máquina remota con GPU mientras vos escribís desde tu notebook en la laptop. El kernel de Python (IPython) es el más común, pero el protocolo es agnóstico: hay kernels para R, Julia, Scala, y una lista larga más.

Cada notebook se guarda como un archivo .ipynb, que en el fondo es JSON puro: código, metadata, y los outputs (texto, imágenes en base64, tablas HTML) todo mezclado en la misma estructura. Ahí nace la mitad de las cosas buenas y la mitad de los dolores de cabeza que vamos a hablar después.

# celda 1: cargamos datos, esto podés re-ejecutar mil veces
# sin perder el estado de las variables anteriores
import pandas as pd

df = pd.read_csv("ventas.csv")
df.head()  # el output queda embebido en el notebook, no hace falta print()

# celda 2: usás %time para medir performance sin instrumentar código
# esto es lo que hace que iterar sea tan rápido comparado con un script .py
%time resultado = df.groupby("categoria")["monto"].sum()
resultado.plot(kind="bar")  # el gráfico se renderiza inline, abajo de la celda

La integración con numpy, pandas, matplotlib es nativa en el sentido de que el ecosistema entero de Python científico fue diseñado (o se adaptó) pensando en que iba a vivir dentro de un notebook. Es software libre, bajo licencia BSD, mantenido por Project Jupyter.

Por qué está en la lista

Tres awesome lists independientes coincidiendo en Jupyter no es casualidad — es consenso de facto. Cuando algo aparece repetido en listas curadas por comunidades distintas (Python general, data science, ML), significa que no es una moda pasajera de seis meses, es infraestructura que la comunidad entera decidió adoptar como estándar.

Lo que lo hace mejor que la alternativa obvia — un script .py con print() everywhere — es que Jupyter resuelve el problema de documentación viva. Un notebook bien armado es simultáneamente el código, el resultado, y la explicación de por qué hiciste lo que hiciste. Compartís un link o un archivo y la otra persona ve exactamente lo que vos viste, sin tener que correr nada. Ese punto — código, resultado y razonamiento en el mismo lugar — es la razón concreta por la que un research paper con notebook adjunto es más fácil de auditar que uno con un repo de scripts sueltos: no tenés que reconstruir el estado mental de quien lo escribió, ya está ahí, congelado.

Cuándo NO usarlo

Acá viene la parte donde tengo que ser honesto y no vendehumos. Jupyter es una máquina de exploración, no una máquina de producción. El formato .ipynb guarda outputs binarios (gráficos en base64, tablas renderizadas) mezclados con el código en el mismo JSON, y eso hace que versionar con git sea un dolor real. Un diff de un notebook no te muestra "cambié esta línea", te muestra un blob de JSON ilegible porque cambió un pixel en un gráfico. Herramientas como nbdime existen específicamente para mitigar esto, y si trabajás en equipo con notebooks compartidos, instalarla no es opcional, es supervivencia.

Tampoco lo uses si tu notebook está creciendo sin límite — la performance se cae en serio con archivos que superan los 100MB, porque el navegador tiene que renderizar todo ese historial de outputs acumulados. Ahí la solución no es "aguantar", es limpiar outputs viejos o directamente migrar la lógica estable a un módulo .py normal e importarlo. Y si lo que necesitás es correr un pipeline de datos de forma automatizada y reproducible (no exploratoria), no uses un notebook a pelo: mirá Papermill para parametrizar y ejecutar notebooks como jobs, o directamente convertí el análisis a script plano con Jupytext, que te deja tener el mismo contenido en formato .py versionable y notebook interactivo al mismo tiempo.

Mi límite personal, después de ese quilombo del scoring: si un notebook va a vivir más de dos semanas o va a tocarlo más de una persona, empieza a valer la pena partirlo — la lógica estable a un .py, y dejar el notebook solo para la parte exploratoria que sigue viva. No es una regla universal, es el criterio que a mí me evitó otro dolor de cabeza.

Cierre

Jupyter pasó el filtro de esta serie por lo mismo que pasaron XGBoost y Netron antes: no es la herramienta más nueva ni la más sexy, es la que la comunidad eligió una y otra vez porque resuelve un problema real sin vueltas.

Lo incómodo que no te van a decir en un tutorial: si tu equipo de data science sigue peleando con git y notebooks gigantes, el problema no es que "no saben versionar". Es que nadie trazó la línea entre explorar y producir. Esa conversación es más difícil que instalar nbdime, pero es la que realmente resuelve el quilombo.

Si te perdiste algún capítulo, la serie completa está en /blog/series/awesome-curated-tools. Nos vemos en la próxima herramienta que sobrevivió al filtro.

---

Este artículo fue publicado originalmente en juanchi.dev