¡Nunca vuelvas a tener un Jupyter Notebook inmantenible!

Hola, amigos. Hoy estamos aquí para hablar sobre Jupyter Notebooks y cómo mantenerlos mantenibles. Comenzaremos con un ejemplo motivador, en el cual presentaré el caso de por qué podrías estar interesado en usar Jupyter Notebooks en primer lugar. Luego, abordaré un par de desafíos que las personas suelen mencionar al intentar mantener sus Jupyter Notebooks mantenibles.

El primero tiene que ver con el control de versiones, y cualquiera que haya intentado ver la diferencia entre dos notebooks usando git diff sabrá de qué estoy hablando. No es fácil. El segundo tiene que ver con la integración continua y, más específicamente, la falta de herramientas de calidad de código disponibles para ejecutar en Jupyter Notebooks.

Entonces, finalmente, demostraré un flujo de trabajo para mantener tus Jupyter Notebooks mantenibles. Vamos directo a nuestro ejemplo motivador. He preparado un flujo de trabajo de ciencia de datos bastante estándar aquí, absolutamente estándar. Lo recorreremos en un segundo. Ahora, podrías preguntarte por qué te estoy mostrando un flujo de trabajo de ciencia de datos absolutamente estándar, y ten paciencia, puede haber un giro al final, puede. Así que vamos a recorrerlo.

Comenzamos leyendo cuatro archivos CSV utilizando Pandas read CSV, bastante estándar. Cada uno de ellos tiene dos columnas, x e y, bastante estándar. Luego, imprimiremos algunas estadísticas resumidas, por lo que imprimiremos la media de x, la media de y, la desviación estándar de x, la desviación estándar de y y la correlación entre x e y. Haremos esto para los cuatro conjuntos de data, aún bastante estándar.

Y luego, utilizando Scikit-learn, para cada uno de estos conjuntos de data ajustaremos un modelo de regresión lineal, también bastante estándar, e imprimiremos el error cuadrado medio, también absolutamente estándar.

Entonces, ¿dónde está el giro? Bueno, veamos qué sucede si ejecutamos esto usando Python. Correcto, mira eso. Si observamos lo que se ha impreso en la consola, veremos que la media de x es la misma para los cuatro conjuntos de data, pero también lo es la media de y, la desviación estándar de x, la desviación estándar de y, la correlación entre x e y, y el error cuadrado medio al ajustar un modelo de regresión lineal también es casi idéntico. Entonces, si observamos esto, podemos decir que los cuatro conjuntos de data deben ser bastante similares. Eso es lo que estas estadísticas resumidas nos están diciendo.

Ahora, intentemos hacer algo ligeramente diferente. Repitamos este análisis, pero en lugar de hacerlo en un script de Python, hagámoslo en un cuaderno de Jupyter. Haremos lo mismo. Simplemente leeremos estos conjuntos de data utilizando pandas.read.csv y ajustaremos un modelo de regresión lineal utilizando scikit-learn. Pero luego, en lugar de simplemente imprimir algunas estadísticas resumidas, visualizaremos nuestros conjuntos de data y también visualizaremos las líneas de regresión lineal, que habremos ajustado. Y debido a que acabamos de imprimir las estadísticas resumidas y eran las mismas para los cuatro conjuntos de data, esperamos que los cuatro gráficos se vean casi idénticos. Así que, vamos. Listos, preparados, ya.

Oh, ¿qué está pasando? Parece que tal vez estos cuatro conjuntos de data no son tan similares después de todo. Sin embargo, si contrastamos esto con lo que vimos hace un segundo cuando solo imprimimos algunos números en la consola, ahora podemos decir que los cuatro conjuntos de data no son realmente iguales. Simplemente tienen algunas características compartidas. Pero cuando solo nos basamos en números individuales como estadísticas resumidas, no podíamos decir eso. Sin embargo, es frustrantemente común ver flujos de trabajo de data science en los que las personas simplemente cargan los data, ajustan un modelo y luego imprimen algunos números sin molestarse en visualizarlo. Así que ese es el ejemplo motivador. Espero que este ejemplo motivador haya resaltado la importancia de visualizar tus data. Y los cuadernos de Jupyter son una excelente manera de hacerlo. Pero si los cuadernos de Jupyter son tan buenos, ¿por qué a veces son criticados? Bueno, dije antes que plantean un problema cuando se trata de control de versiones. Y para cualquiera que no haya intentado hacer eso antes, veamos juntos a qué me refiero. Guardemos el cuaderno tal como está. Y hagamos un commit. git commit run notebook. Ahora hagamos un cambio absolutamente trivial. Simplemente agreguemos una pequeña línea aquí que diga fig subplot title Data Frames. Ya sabes, un cambio realmente pequeño. Ejecutemos la celda nuevamente. Lo único que ha cambiado es que he agregado este título. Si esto fuera un script de Python y solo hubiéramos cambiado una línea de código, entonces si hiciéramos git diff, veríamos una diferencia realmente pequeña. Sin embargo, esto no es un script de Python. Es un cuaderno de Jupyter. Y así que si guardamos y hacemos git diff, mira lo que sucede.

Obtenemos esta diferencia de imagen en bruto absolutamente horrenda e irrazonable. Miro esto y no tengo idea de lo que está sucediendo. Me hace querer dejar de usar los cuadernos de Jupyter para siempre. Sin embargo, todo está perdido, porque tal vez no sea tanto que los cuadernos de Jupyter no funcionen bajo control de versiones, tal vez solo necesitamos una herramienta más especializada.

Y una de esas herramientas, que les presentaré hoy, se llama nbdyme. La forma en que nbdyme funciona es que lo llamas desde la línea de comandos, como nbdiff-web, y luego, permíteme permitir eso, y obtendrás una URL que puedes abrir en tu navegador, y ahora obtenemos una vista visualmente agradable y fácil de entender de la diferencia entre los cuadernos. Ahora, si miramos esto, está absolutamente claro que solo ha cambiado una línea de código. También podemos comparar fácilmente la diferencia en las salidas y ver que solo ha cambiado el título. Esto es mucho más fácil de leer en comparación con lo que teníamos hace unos minutos. Esta diferencia absolutamente ilegible, ahora tenemos algo visualmente agradable que me hace querer usar los cuadernos de Jupyter nuevamente. Genial. Entonces no era que los cuadernos de Jupyter no funcionaran con el control de versiones. Era más que necesitábamos una herramienta especializada. Entonces ese es el primer desafío cuando se trata de los cuadernos de Jupyter que mencioné anteriormente. Ahora veamos el siguiente. Porque si estás manteniendo las cosas bajo control de versiones, es probable que no solo estés viendo la diferencia entre las versiones de tu código, también estarás ejecutando integración continua. Si estás acostumbrado a hacer integración continua en tus scripts de Python, es probable que estés acostumbrado a ejecutar una suite completa de linters y formateadores en tu código como black, isort, flake8, pyupgrade, mypy, la lista continúa. Si le dices a alguien que está acostumbrado a hacer eso que de repente tienen que cambiar a usar cuadernos de Jupyter, para los cuales no tendrán disponible esa gran suite de herramientas, entonces es posible que se sientan con razón como llorar. Pero ¿eso significa que todo está perdido, o nuevamente, significa que solo necesitamos una herramienta más especializada? Veamos. Necesitaríamos una herramienta que convierta temporalmente tu cuaderno en un script de Python y lo guarde en un directorio temporal, ejecute estas herramientas de calidad de código en él, reconstruya el cuaderno y pase la salida. Y una de esas herramientas, que les presentaré hoy, se llama NBQA. Veamos cómo funciona un poco. He preparado aquí un cuaderno para ustedes, que produce un gráfico bonito al final, que se toma de la galería de matplotlib, pero dentro de él he escrito un código intencionalmente distorsionado. Veamos qué sucede cuando ejecutamos NBQA y luego algunas herramientas de calidad de código en él. Puedes ejecutar NBQA desde la línea de comandos. De hecho, ni siquiera necesitas tener tu cuaderno abierto o tener una instancia de Jupyter ejecutándose. Entonces, veamos qué sucede. Vamos a formatearlo automáticamente usando black. Luego ordenemos las importaciones usando isort. Luego actualizaremos la sintaxis usando pyupgrade, y finalmente ejecutaremos flake8, que no modificará nuestro cuaderno.

Solo nos informará si hay alguna violación de la guía de estilo. Y, de hecho, nos dice que hay una importación que no se utiliza, Seaborn. Entonces, podemos abrir nuestro cuaderno nuevamente, eliminar esta importación no utilizada y ahora, veamos qué ha cambiado.

Para ver qué ha cambiado, vamos a hacer git diff, excepto que no vamos a hacer git diff. Acabo de decirte que deberíamos usar nb-dime para ver la diferencia entre los cuadernos. Entonces, vamos a usarlo. Abramos este enlace en nuestro navegador y ahora, veamos qué ha cambiado.

Entonces, en primer lugar, verás que las importaciones ahora se han ordenado gracias a isort. Esta importación no utilizada se ha eliminado gracias a flakeate. Este constructor obsoleto de este diccionario se ha reemplazado por uno más moderno gracias a pyupgrade. Esta indentación inconsistente se ha solucionado gracias a black y de repente, el estilo del código se siente mucho más uniforme y será más fácil mantener una calidad consistente. Será más fácil comparar las diferencias cuando diferentes personas lo hayan modificado, si el estilo es consistente.

Genial, excepto que no solo queremos que nuestro cuaderno tenga una cierta code quality hoy. Queremos asegurarnos de que se mantenga así en el futuro y una forma popular de hacerlo es a través de una herramienta llamada Precommit. La forma en que funciona Precommit es que necesitas un archivo .precommit config.yaml en el que especifiques los repositorios que alojan las herramientas de code quality que deseas ejecutar en tus archivos. Aquí estaré usando NVQA. Especificas una revisión, en este momento estoy poniendo 0.3.3, pero siempre debes verificar cuál es la última versión, y probablemente poner esa. Y luego especificas qué hooks quieres ejecutar. Así que ejecutaré nbqa-black, nbqa-iSort, nbqa-pyupgrade y nbqa-flake8. Esto es exactamente lo que teníamos antes, pero ahora lo he puesto en mi archivo pre-commit. Entonces, lo que sucederá ahora es que si hacemos un commit que incluya un cuaderno, pre-commit ejecutará todas estas verificaciones de code quality automáticamente y bloqueará nuestro commit si no pasan todas. Excepto, lo siento, necesitamos habilitar pre-commit en nuestro espacio de trabajo para que funcione. Entonces, hagamos un reset notebook. Ahora agreguémoslo nuevamente. Hagamos commit. Muy bien y ahora verás que ha ejecutado nuestras herramientas de code quality. Tuve que hacer esto dos veces para que todas pasaran y la segunda vez pre-commit nos permitió hacer el commit. Entonces, si usas pre-commit, te asegurarás de que no solo tus cuadernos pasen las verificaciones de code quality hoy, sino también que continúen pasando las verificaciones de code quality en el futuro. También puedes ejecutar pre-commit durante tu integración continua. Y así te asegurarás de que cualquier cambio entrante en tu repositorio pase.

Siguiente pregunta. ¿Sería seguro decir que NBQA es similar a integrar un IDE en un cuaderno Jupyter y agregarle algunos esteroides? Me sorprende que nadie haya pensado en esto antes. Excelente trabajo. Oh, gracias. Eso es muy amable de tu parte. Me gustaría pensar en ello de esa manera. Creo... Estoy tratando de recordar su nombre. El tipo que hizo fast.ai, Jeremy Howard, describe los cuadernos Jupyter como una encarnación del entorno de programación literaria, que fue concebido por Donald Knuth, si no me equivoco. Y creo que es una lástima que muchas de las prácticas de desarrollo estándar, que están disponibles cuando programamos en scripts de Python, no estén tan fácilmente disponibles cuando programamos en cuadernos Jupyter. Y dado algunos de los beneficios que proporcionan al hacer ciencia de datos, creo que cualquier herramienta que nos ayude a programar de manera más cómoda y mantenible dentro de un cuaderno, me gustaría pensar que sería bienvenida.