IPython o Jupyter?

Sage Notebook

Il notebook Sage come sistema basato su browser fu rilasciato per la prima volta a metà anni 2000 e poi, nel 2007, uscì una nuova versione più potente, con account utente e la possibilità di rendere pubblici i documenti. Ricordava l'interfaccia di Google Docs, dato che il layout del notebook Sage si basava su quello dei notebook Google.

I creatori dei notebook Sage hanno confermato di essere stati assidui utilizzatori dei notebook Mathematica e dei fogli Maple. Altre motivazioni o driver importanti nello sviluppo dei notebook Sage furono i seguenti: primo, gli sviluppatori erano in stretto contatto con il team dietro IPython, anche perché la versione basata su terminale di Sage usava IPython. Secondo, ci fu "un tentativo fallito" da parte di due studenti di fornire una GUI per IPython; terzo, l'ascesa delle applicazioni web "AJAX" (acronimo pseudo per "Asynchronous JavaScript And XML"), che non richiedevano agli utenti di ricaricare l'intera pagina a ogni azione.

Questo avviene, ad esempio, quando compili un modulo su un sito: senza AJAX, quando clicchi su invia vieni reindirizzato a una nuova pagina con nuove informazioni dal server. Con AJAX, JavaScript invia la richiesta al server, ottiene i risultati e aggiorna lo schermo. Non devi ricaricare, né vieni reindirizzato.

Altre applicazioni AJAX che potresti conoscere sono, ad esempio, Gmail, Google Maps, Facebook, Twitter, … Come vedi, quasi tutto è AJAX.

IPython e Jupyter Notebook

Alla fine del 2001, circa vent'anni dopo che Guido van Rossum iniziò a lavorare su Python al National Research Institute for Mathematics and Computer Science nei Paesi Bassi, Fernando Pérez iniziò a sviluppare IPython. Il progetto fu fortemente influenzato dai notebook Mathematica e dai worksheet Maple, proprio come il notebook Sage e molti altri progetti che seguirono.

Nel 2005 ci fu un primo tentativo di costruire un sistema di notebook con Wx, un toolkit di widget e una libreria di strumenti per creare interfacce grafiche utente (GUI) per applicazioni multipiattaforma. Due studenti del Google Summer of Code lavorarono al prototipo sotto la direzione di Robert Kern e Fernando Pérez. Successivamente, Robert lavorò ancora un po' sul problema. Era meno un prototipo di sistema notebook e più una pulizia del core di IPython con l'idea di rendere più facile scrivere un frontend GUI wxPython per la shell di IPython. Furono proprio queste pulizie a contribuire a creare un sistema notebook pulito e alcune di esse vennero integrate gradualmente in IPython quando l'iniziativa del notebook, poi coronata dal successo, prese piede.

Il secondo prototipo per IPython fu costruito nell'estate del 2006 da Min Ragan-Kelley, sotto la supervisione di Brian Granger. Era basato sul web e aveva un backend con database SQL, ma il lavoro fu interrotto perché l'implementazione si rivelò troppo complessa con le tecnologie web dell'epoca.

Il terzo prototipo dell'IPython notebook arrivò nell'ottobre 2010 e fu realizzato da terzi in pochi giorni di hack. Infine, tra la primavera e l'estate del 2011, Brian Granger lavorava a tempo pieno sul prototipo del notebook web, basandosi su lavori svolti nel 2010, quando creò l'architettura del kernel IPython e la specifica dei messaggi con Fernando Pérez e PyZMQ con Min Ragan Kelley.

PyZMQ è una libreria che fornisce i binding Python per ZeroMQ; Questa libreria era necessaria per le funzionalità di calcolo parallelo di IPython, la console qt e il notebook.

PyZMQ e i websocket furono le principali tecnologie che resero possibile il notebook. In autunno dello stesso anno, anche altri contributori (come Matthias Bussonnier, Min e Fernando) vi stavano contribuendo. Il 21 dicembre 2011 fu rilasciata la prima versione di IPython Notebook (0.12).

Negli anni successivi, il team ricevette premi, come l'Advancement of Free Software per Fernando Pérez il 23 marzo 2013 e il Jolt Productivity Award, e finanziamenti dalla Alfred P. Sloan Foundation, tra gli altri.

Infine, nel 2014, nacque Project Jupyter come progetto spin-off da IPython.

L'ultima release di IPython prima della separazione conteneva una shell interattiva, il server notebook, la console Qt, ecc., in un unico repository. Il progetto era grande, con componenti che stavano diventando sempre più progetti distinti che per caso appartenevano allo stesso progetto.

Ma nota che la dimensione del progetto non fu l'unico motivo per cui nacque Project Jupyter: dal 2011 al 2014, l'IPython notebook iniziò a funzionare con altri linguaggi di programmazione. Il primo fu Julia, poi R. Il fatto che l'IPython notebook, che implicava un notebook basato esclusivamente su Python, funzionasse anche con kernel di altri linguaggi come Julia e R, lasciava perplessi.

Perché chiamarlo "IPython" se c'erano coinvolti anche altri linguaggi?

Il nome "Jupyter" fu ispirato dai principali linguaggi open per la scienza (cioè Julia, Python e R) e, anche se può sembrare un altro acronimo, non ha mai significato che altri linguaggi non fossero i benvenuti. Anzi, il nome rappresentava meglio il progetto su cui gli sviluppatori stavano lavorando e strizzava l'occhio alle radici scientifiche del progetto!

Dopo l'avvio di Project Jupyter, le parti agnostiche rispetto al linguaggio del progetto IPython, come il formato del notebook, il protocollo dei messaggi, la console Qt, l'applicazione web del notebook, ecc., furono spostate nel progetto Jupyter. Puoi trovare l'organizzazione principale di Jupyter su GitHub qui.

Nelle comunità Jupyter e IPython, questo è chiamato "The Big Split".

IPython oggi ha solo due ruoli da svolgere: essere il backend Python di Jupyter Notebook, noto anche come kernel, e una shell interattiva Python. Ma non è tutto: nell'ecosistema IPython trovi anche un framework per il calcolo parallelo. Ne leggerai di più tra poco!

E proprio come IPython, Project Jupyter è in realtà un nome ombrello per più progetti: le tre applicazioni principali che raccoglie sono il Notebook stesso, una Console e una Qt console, ma ci sono anche sotto-progetti come JupyterHub per supportare il deployment dei notebook, nbgrader per fini didattici, ecc. Puoi vedere una panoramica dell'architettura Jupyter qui.

Nota che è proprio l'evoluzione di questo progetto a spiegare la confusione che molti Pythonisti hanno riguardo a IPython e Jupyter: dal momento che uno è nato dall'altro (abbastanza di recente), c'è chi fa ancora fatica ad adottare i nomi corretti per i concetti. Ma forse il fattore ancora più complicante è l'evoluzione stessa: poiché uno è nato dall'altro, c'è una notevole sovrapposizione tra le funzionalità di IPython e di Jupyter Notebook che a volte è difficile distinguere! Come distinguerli diventerà chiaro nelle prossime sezioni del post. Se vuoi sapere più dettagli su come è nato lo sviluppo di IPython, consulta i resoconti personali di Fernando Pérez e William Stein sulla storia dei loro notebook.

Notebook R

R Markdown e Jupyter Notebook condividono l'obiettivo di fornire un flusso di lavoro riproducibile, intrecciando codice, output e testo in un unico documento, supportando widget interattivi e l'esportazione in più formati.

Tuttavia, differiscono anche: il primo punta all'esecuzione batch riproducibile, alla rappresentazione in testo semplice, al controllo versione, all'output di produzione e offre lo stesso editor e gli stessi strumenti che usi per gli script R. Il secondo punta a mostrare l'output in linea con il codice, a mettere in cache l'output tra le sessioni, a condividere codice e output in un unico file. I notebook hanno un'enfasi su un modello di esecuzione interattivo. Non usano una rappresentazione in testo semplice, ma una rappresentazione con dati strutturati, come JSON.

Questo spiega lo scopo dell'applicazione notebook di RStudio: combina tutti i vantaggi di R Markdown con i punti di forza dei notebook computazionali.

Per scoprire di più su come lavorare con i notebook R e quali sono le differenze esatte tra i notebook Jupyter e R Markdown in termini di condivisione, gestione dei progetti, controllo versione e altro, leggi il post di DataCamp Jupyter e R: notebook con R.

Altri notebook per la data science

Ovviamente, ci sono ancora più notebook da considerare quando inizi con la data science. Negli ultimi anni, molte nuove alternative sono arrivate a data scientist e appassionati: pensa non solo a Beaker Notebook, Apache Zeppelin, Spark Notebook, DataBricks Cloud, ecc., ma anche ad altri strumenti come l'IDE Rodeo o nteract, che rendono le tue analisi di data science interattive e riproducibili. Da notare che nteract differisce dagli altri strumenti qui menzionati perché utilizza l'architettura Jupyter, come i protocolli e i formati.

Plotting

Una caratteristica importante del kernel IPython è la possibilità di visualizzare i grafici prodotti dall'esecuzione delle celle di codice. Il kernel è progettato per lavorare senza soluzione di continuità con la libreria di visualizzazione dati matplotlib per fornire questa funzionalità. Per usarla, impiega il comando magic %matplotlib.

Così, il grafico verrà visualizzato in una finestra separata per impostazione predefinita. In più, puoi specificare un backend, come inline o qt, e l'output dei comandi di plotting verrà mostrato in linea o tramite un backend GUI diverso. Puoi leggere di più qui.

Navigazione del file system

Le magic del kernel forniscono anche un modo per navigare nel file system. Le magics %cd e %bookmark possono essere usate per cambiare directory o per salvare un segnalibro su una cartella a cui accedi spesso.

Accesso al debugger

Puoi anche usare le magics per richiamare un debugger Python %pdb ogni volta che c'è un'eccezione non gestita. Questo ti guiderà attraverso la parte di codice che ha generato l'eccezione, rendendo possibile trovare rapidamente la fonte del bug.

Puoi anche usare la magic %run con l'opzione -d per eseguire script sotto il controllo del debugger di Python. Imposterà automaticamente i breakpoint iniziali per te. Infine, puoi usare la magic %debug per un accesso al debugger ancora più semplice.

Estensioni IPython

Puoi usare la magic %load_ext per caricare un'estensione IPython tramite il suo nome di modulo. Le estensioni IPython sono moduli Python che modificano il comportamento della shell: possono registrare magics, definire variabili e in generale modificare lo spazio dei nomi dell'utente per fornire nuove funzionalità da usare nelle celle di codice. Ecco alcuni esempi:

• Usa %load_ext oct2py.ipython per chiamare senza soluzione di continuità file M e funzioni Octave da Python,
• Usa %load_ext rpy2.ipython per usare un'interfaccia a R in esecuzione incorporata in un processo Python,
• Usa %load_ext Cython per usare un compilatore da Python a C,
• Usa sympy.init_printing() per stampare in modo elegante gli oggetti Sympy Basic automaticamente, e
• Per usare Fortran nella tua sessione interattiva, puoi usare %load_ext fortranmagic.

… Ce ne sono molte altre! Puoi creare e registrare le tue estensioni IPython su PyPi: questo significa anche che esistono molte altre estensioni e magics definite dagli utenti! Un esempio è ipython_unittest, ma consulta anche questo Indice delle estensioni.

Un'altra estensione da tenere d'occhio è sparkmagic, un set di strumenti per lavorare in modo interattivo con cluster Spark remoti tramite Livy, un server REST per Spark, nei notebook Jupyter. La libreria sparkmagic fornisce una magic %%spark che puoi usare per eseguire facilmente codice su un cluster Spark remoto da un normale notebook IPython.

# Load in sparkmagic
%load_ext sparkmagic.magics
 
# Set the endpoint
%manage_spark
 
# Ask for help
%spark?

Vai qui per altri esempi su come usare queste magics per lavorare interattivamente con un cluster Spark.

Nota che IPython ha altre due magics oltre a %load_ext che ti consentono di gestire le estensioni dall'interno del tuo Jupyter Notebook: %reload_ext e %unload_ext per scaricare, reimportare e caricare un'estensione e per scaricare l'estensione, rispettivamente.

Kernel diversi, altre magics

Tuttavia, in altri linguaggi l'elemento sintattico dei comandi magic potrebbe avere un significato. Il kernel R, IRKernel, non ha un sistema di magics. Per eseguire comandi bash, ad esempio, userai funzioni R come system() per richiamare un comando del sistema operativo. Un esempio sarebbe system("head -5 *.csv", intern=TRUE). Nota che includendo l'argomento intern, specifichi di voler catturare l'output del comando come vettore di caratteri in R. Per visualizzare markup markdown, usi display_markdown(), a cui passi il codice Markdown come vettore di caratteri. Allo stesso modo, il kernel Julia IJulia non usa le "magics". Invece, altre sintassi per ottenere gli stessi obiettivi sono più naturali in Julia, funzionano in ambienti al di fuori delle celle di codice IJulia e sono spesso più potenti. Tuttavia, gli sviluppatori del kernel IJulia hanno fatto in modo che ogni volta che inserisci un comando magic di IPython in una cella IJulia, vedrai una stampa di aiuto che spiega come ottenere un effetto simile in Julia, se possibile.

Ad esempio, l'analogo di %load di IPython in IJulia è IJulia.load().

D'altra parte, ci sono kernel come il kernel Scala IScala che supportano i comandi magic in modo simile a IPython. Tuttavia, il set di magics è diverso perché deve adattarsi alle specificità di Scala e della JVM. I comandi magic consistono in un simbolo di percentuale % seguito da un identificatore e da un input opzionale. Alcune delle magics più note sono:

# Type Information
%type 1
 
# Library Management
%libraryDependencies
%update

Come hai letto sopra, la libreria sparkmagic fornisce anche una serie di kernel Scala e Python che consentono di collegarsi automaticamente a un cluster Spark remoto, eseguire codice e query SQL, gestire il server Livy e la configurazione dei job Spark e generare visualizzazioni automatiche. E tutto questo senza bisogno di codice!

Ad esempio, puoi eseguire facilmente query SparkSQL con %%sql o accedere alle informazioni e ai log delle applicazioni Spark tramite la magic %%info.

Se stai lavorando con un altro kernel e ti chiedi se puoi usare i comandi magic, può essere utile sapere che ci sono alcuni kernel che si basano sul progetto metakernel e che, nella maggior parte dei casi, useranno le stesse magics che trovi anche nel kernel IPython. Puoi trovare un elenco delle magics di metakernel qui. Metakernel è un template di kernel Jupyter/IPython che include funzioni magic di base.

Alcuni esempi:

• Il kernel MATLAB matlab_kernel,
• Il kernel Octave octave_kernel,
• Il kernel Java9 java9_kernel,
• Il kernel Wolfram wolfram_kernel,
• Il kernel SAS. … E molti altri!

Ciò significa che, ad esempio, quando usi il kernel MATLAB, avrai a disposizione le seguenti magics:

Available line magics:
%cd  %connect_info  %download  %edit  %get  %help  %html  %install  %install_magic  %javascript  %kernel  %kx  %latex  %load  %ls  %lsmagic  %magic  %parallel  %plot  %pmap  %px  %python  %reload_magics  %restart  %run  %set  %shell  %spell
 
Available cell magics:
%%debug  %%file  %%help  %%html  %%javascript  %%kx  %%latex  %%processing  %%px  %%python  %%shell  %%show  %%spell

Se guardi il blocco stampato sopra, vedrai che alcuni di questi comandi magic suonano molto familiari. Per chi non conosce bene le magics, confronta il blocco sopra con le magics disponibili di default nel kernel IPython e vedrai che alcune sono le stesse:

Available line magics:
%alias  %alias_magic  %autocall  %automagic  %autosave  %bookmark  %cat  %cd  %clear  %colors  %config  %connect_info  %cp  %debug  %dhist  %dirs  %doctest_mode  %ed  %edit  %env  %gui  %hist  %history  %killbgscripts  %ldir  %less  %lf  %lk  %ll  %load  %load_ext  %loadpy  %logoff  %logon  %logstart  %logstate  %logstop  %ls  %lsmagic  %lx  %macro  %magic  %man  %matplotlib  %mkdir  %more  %mv  %notebook  %page  %pastebin  %pdb  %pdef  %pdoc  %pfile  %pinfo  %pinfo2  %popd  %pprint  %precision  %profile  %prun  %psearch  %psource  %pushd  %pwd  %pycat  %pylab  %qtconsole  %quickref  %recall  %rehashx  %reload_ext  %rep  %rerun  %reset  %reset_selective  %rm  %rmdir  %run  %save  %sc  %set_env  %store  %sx  %system  %tb  %time  %timeit  %unalias  %unload_ext  %who  %who_ls  %whos  %xdel  %xmode
 
Available cell magics:
%%!  %%HTML  %%SVG  %%bash  %%capture  %%debug  %%file  %%html  %%javascript  %%js  %%latex  %%perl  %%prun  %%pypy  %%python  %%python2  %%python3  %%ruby  %%script  %%sh  %%svg  %%sx  %%system  %%time  %%timeit  %%writefile

In sostanza, puoi usare una domanda per distinguere quali magics sono specifiche di IPython e quali possono essere usate in altri kernel: questa funzionalità è specifica di Python o è una cosa generale che può essere usata anche nel linguaggio con cui stai lavorando?

Ad esempio, %pdb, il Python Debugger, o %matplotlib sono specifici di Python e non avrebbero senso quando lavori con il kernel JavaScript. Tuttavia, cambiare directory con %cd è tipicamente qualcosa di molto generale che dovrebbe funzionare in qualsiasi linguaggio, essendo un comando così "generale". Quindi, è probabile che questa sia una magic utilizzabile anche in altri kernel. Ovviamente, dovrai comunque sapere se il tuo kernel fa uso delle magics.