Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.

Io ho un setup del tutto nuovo e ho il terrore maledetto che qualcosa esploda ma non deve esplodere e non esploderà quindi massima tensione anche perché l'ospite di oggi, piccola anticipazione, è un ospite speciale che sta curando, ha curato due cose che sono state nella bocca di molti, nel senso che se ne è parlato parecchio e oggi è qua a Gitbar per parlarne anche con noi.

Ma prima di svelarvi chi è, tanto non ve lo dico, e non ve lo dico almeno prima di avervi ricordato i nostri contatti, infochiocio la gitbar.it ettbrainrepo su twitter e poi il nostro gruppo telegram, il posto dove ci incontriamo a chiacchierare del più e del meno, stavo guardando le discussioni di oggi, sono variegate, siamo 1178 membri quindi stiamo sempre più crescendo e se non vi siete iscritti mi raccomando fatelo perché è là che andate a trovare il vero cuore del nostro podcast.

Benvenuti su Gitbar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.

Ma bando alle ciance vi presento l'ospite di oggi, abbiamo con noi Antonio Cuni, chi ha scritto del codice python non può non conoscerlo perché in realtà oggi è principal software engineer a Anaconda e poi vediamo per i pochi che non sanno cos'è Anaconda di cosa si tratta, ma è stato anche core developer di PiPi, hai lavorato e stai lavorando sul nuovo progetto HPI giusto Antonio? Ho detto bene? Hai detto bene, HPI in realtà.

Sapi che io sto tipo dicendo sigle a caso perché sono completamente il newbod del mondo python, credo di aver scritto 100 righe di codice python in vita mia quindi se dico cazzate mi raccomando correggimi ti prego.

I miei colleghi che mi dicono che soppreno tutte le lettere e ci metto la lettera Pi in fondo quindi i prossimi progetti sarà lettera a caso.

Dimmi una cosa, allora per quanto riguarda PiPi è stato il tuo precedente progetto giusto? Sì in realtà sono ancora formalmente core developer di PiPi anche se ultimamente oggettivamente ho lavorato poco su PiPi da un paio di anni perché appunto mi sono dedicato su HPI che è da un certo punto di vista uno spin off e quindi tutto il mio lavoro che ho fatto su PiPi negli ultimi due o tre anni è stato mirato a supportare HPI.

Domanda abbiamo detto PiPi e HPI per chi non conoscesse il mondo python di cosa si tratta? Allora abbiamo, cerco di sintetizzare perché ho aperto il vaso di Pandora tipo.

Allora PiPi è un'implementazione alternativa di Python, la maggior parte della gente conosce Python perché lo installa in vari modi o da python.org o usando Anaconda ad esempio e poi la command line esegue i programmi scrivendo python mioprogramma.py e questo viene eseguito dall'interprete python che quello di default è chiamato CPython che sta per classical python o python scritto in C.

PiPi è un'implementazione alternativa ovvero un altro programma che la command line si chiama PiPi che prende il tuo sorgente codice sorgente scritto in python e lo esegue e uno dice vabbè perché dovrei il punto di PiPi essere più veloce perché usa tecniche anche relativamente avanzate di compilazione just in time per cui alla fine riesce a ottenere performance migliori di quelle che hai con CPython in determinati casi con determinati trade off ci sono dei casi d'uso in cui PiPi è un'ottima soluzione degli altri in cui non serve o non è così utile però l'obiettivo principale di PiPi era questo qua.

Ok hai anche citato HPy e l'hai introdotto come spin off qual è l'obiettivo di HPy cosa si propone di fare? Lo si capisce bene se parliamo di quello che è il tallone d'Achille principale di PiPi che sono le estensioni scritte in C, le C extension di CPython perché quando tu installi una libreria in python con pip install o con install pip o Pluto queste librerie possono essere di due tipi o scritte in pure python quindi del codice python esattamente come quello che scriviamo noi oppure delle estensioni scritte in C compilate da un compilatore e distribuite sotto forma di codice eseguibile che intenzionalmente sono più veloci proprio perché il C è più veloce di python e ad esempio quasi tutte le librerie scientifiche dell'ecosistema python sono scritte in C non Pi, grosse parti di SciPy, Pandas, Pytorch tutto l'ecosistema è scritto in C.

Queste estensioni per parlare con l'interprete python che le esegue usano quello che è un API che è stata sviluppata nel corso degli anni da Guido Van Rossum e dagli altri Cpython developer che è include python.h.

Chiunque ha scritto in estensione C inizia il suo sorgente con include python.h in C.

Il problema è che questa API è estremamente tied, adesso mi viene in italiano, ma accoppiata bravo ai dettagli interni di Cpython quindi significa che per un interprete alternativo che usa dei dettagli implementativi diversi diventa veramente difficile poterlo implementare in maniera efficiente.

PyPy supporta le C extension in maniera quasi totale, cioè quindi su PyPy si possono usare NumPy, SciPy eccetera, ma visto che dobbiamo emulare il comportamento di Cpython vanno molto più lenti di quello che dovrebbero e potrebbero.

Quindi tendenzialmente un programma PyPy eseguito sotto PyPy è molto molto veloce nelle parti più python e molto più lento, o un po' più lento, nelle parti scritte in C delle C extension.

Hpy è un progetto che mira tra le altre cose a risolvere questo tipo di problema perché l'API è più ad alto livello, quindi l'API che le C extension utilizzano per interfacciarsi con l'interprete è più ad alto livello, non espone dettagli implementativi ed è strutturata in maniera tale che tutti gli interpreti, anche quelli alternativi e anche Cpython ovviamente, lo possano implementare in maniera efficiente.

Quindi se un'estensione è scritta con Hpy anzi che con python.h automaticamente va super veloce su PyPy e stesse performance di prima su Python è molto più veloce su PyPy e sugli altri interpreti perché ad esempio una grossa parte del lavoro è fatta da un team di Oracle che sviluppa GraalPython, che è un'altra implementazione di Python che gira su JVM.

Quindi Hpy è utile anche per loro.

Questa è l'estrema simpesi.

Ti faccio una domanda perché adesso mi sorge mi sorge proprio il dubbio o comunque la curiosità.

Hai già citato tre implementazioni diverse di Python.

Il fatto che ci siano più implementazioni del runtime dove gira poi il linguaggio, ha creato un problema l'ecosistema o è stato un plus, un turbo boost che ha moltiplicato, amplificato l'adozione? Direi entrambe le cose, il fatto che esistano più implementazioni del linguaggio è un fatto importante e positivo e secondo me sottolinea la salute della comunità Python.

Quasi tutti i linguaggi di cui sono conoscenza quando hanno avuto successo hanno avuto altre implementazioni perché quando tu implementi un linguaggio soprattutto dall'alto livello sei sempre costretto a fare dei trade off, può essere maggiore efficienza o maggiore semplicità nel scrivere il codice, minor consumo di RAM, runtime, dimensione del binario più piccola, ci sono un sacco di trade off e ci sta, è assolutamente normale che varie comunità, varie nicchie abbiano differenti esigenze e quindi quasi tutti i linguaggi finiscono per avere più di un'implementazione.

Quindi in questo caso qua è un ottimo segno per Python.

Purtroppo esattamente per il motivo che spiegavo prima le implementazioni alternative si sono sempre scontrate con lo scoglio di queste estensioni C perché dal punto di vista dell'utente comune se io ho Python e implementa, e il mio interprete implementa tutto il linguaggio, anche i corner case, anche le cose più strane in maniera corretta, ma non posso fare import non py, a quel punto non mi serve, oppure serve solo a una piccola fetta.

Se tante cose non le posso usare, le posso usare ma vanno lenti eccetera eccetera, diventa molto meno interessante.

E questo è stato un problema che ha accumulato tutte le estensioni Python, le implementazioni alternative di Python che si sono succedute negli anni.

Ad esempio mi ricordo di Jython che era Python per la JVM, il primo Python per la JVM, adesso ne abbiamo un altro appunto, Iron Python che era Python per Totnet, abbiamo appunto PyPy che supporta varie architetture, queste direi che sono i principali ma probabilmente me ne dimentico alcune di quelle che erano diciamo complete.

Quindi nel corso degli anni abbiamo avuto tantissimi tentativi di faster Python, progetti che miravano a avere un Python più veloce senza rompere la compatibilità con le estensioni, ma hanno fondamentalmente avuto tutti successo parziale e non sono mai riusciti a diventare un'implementazione mainstream o comunque usata.

Quindi che io sappia questi progetti al momento sono più o meno abbandonati.

Ad esempio abbiamo Unload and Swallow che era stato, mi sembra che fosse uscito nel 2007 2008 dai Google Labs.

Recentemente c'è stato Piston, scritto con la Y, non solo la pronuncia, che continua a essere supportato ma che io sappia meno, sviluppato meno attivamente di prima.

Me ne so, sto sicuramente dimenticando qualcuno, ma nessuno ha avuto neanche lontanamente il successo che ha avuto Cpython.

Stiamo parlando di 99% a 1% o cifre anche minore di questa.

Chiaro.

E a proposito di successo, delle librerie che citavi, io ho avuto modo di giocarci giusto un po' con Pandas e NumPy.

Cosa è cambiato? Perché tu lavori nel mondo di Python da prima dell'esplosione della data science, immagino, no? Sì.

E da Pythonista, come hai vissuto questo tipo di evoluzione, questo trend? E come il linguaggio ha risposto a un cambio radicale di mercato o comunque a un ampliamento del mercato? È vero, allora, io ho iniziato con Python nel 2001, mi sembra, quando era un linguaggio soprattutto in Italia molto molto di nicchia e poco conosciuto.

All'università ero l'unico, forse eravamo in due, a conoscere e usare Python per i nostri progetti personali, ma nessuno aveva idea di cosa fosse.

Quindi sì, ho effettivamente vissuto tutte le esplosioni di popolarità di Python.

Cosa è cambiato dal punto di vista utente? Sinceramente faccio fatica a dirlo perché io non sono un data scientist, quindi, benché sappia cosa sono queste librerie, le ho anche usate per fare qualcosina, non ho mai usato seriamente NumPy o Pandas o Matplotlib per fare data science.

Quindi dal punto di vista di quello che io faccio, normalmente questo ecosistema qua non mi serve, non lo uso.

Quello che ho notato è che è cambiato molto la composizione della community, proprio perché adesso abbiamo tante persone che usano Python non come linguaggio, nel senso che sono programmatori a cui piace un linguaggio e hanno scelto Python perché gli piace di più di JavaScript, piuttosto che di C++, piuttosto che di altro, ma lo usano proprio come un tool per risolvere il loro problema che è fare data science, fare questa analisi di dati e Python è diventato il standard de facto per fare questa cosa qua.

Quindi abbiamo tutta una platea di programmatori non di professione, se mi passate il termine, che non vuole assolutamente essere denigrativo, anzi, abbiamo persone che riescono a fare delle cose fantastiche non avendo avuto magari una formazione formale su informatico o computer science.

Sì, sai che dovendo fare un'analogia neanche troppo astratta, ho la stessa percezione nel mondo Scala.

Come la community sa, mia moglie è una data engineer e lavora su Scala.

E quello che vedo anche confrontandomi con i suoi colleghi, con l'ecosistema di cui fa parte, è che in realtà talvolta sì, loro usano Scala, ma sono quasi utilizzatori inconsapevoli di Scala perché utilizzano Spark, perché il loro ecosistema è quello nel caso di Python e NumPy, Pandas e quant'altro.

Quindi alla fine probabilmente neanche hanno contezza della profondità e della potenza anche espressiva del linguaggio.

Sono fondamentalmente d'accordo, è esattamente quello che succede a Python e secondo me è di nuovo un segno positivo, perché vuol dire che il linguaggio era abbastanza potente, espressivo e capibile per poter essere usato da questa nuova platea di utilizzatori che è sicuramente molto diversa da quella che c'era nel 2001, ma anche nel 2010.

Però nel contempo, non lo so, adesso sto lasciando la mente libera di vagare anche di dire stronzate e censurami se ne dico qualcuna, però ho visto nello sviluppare dei linguaggi una certa pressione, una certa spinta verso l'uso idiomatico del linguaggio.

Con l'avvento di questi tool e anche l'apertura al mercato, forse questa strictness idiomatica sia un po' diluita, perché hai figure diverse, con competenze diverse che scrivono codice, e come ha reagito la community dei, passami le virgolette, dei vecchi Pythonisti all'arrivo di questo nuovo codice e soprattutto c'è stata un'apertura? È una domanda molto complessa a cui faccio fatica a rispondere in generale.

Allora, secondo me dobbiamo distinguere tra quello che è l'ecosistema di librerie Python e quello che sono i prodotti finali.

I prodotti finali, ad esempio, sono quelli scritti dai notebook fatti dai data scientist per fare la loro analisi di dati e quelli sono visti da chi li fa, dai loro fruitori, ma non dalla comunità in generale ovviamente.

Quindi non c'è modo di reagire, non ha senso dire come ha reagito la comunità, perché io non li vedo i notebook fatti dai data scientist.

Sì può capitare, ma in generale non è quello che mi passa.

Per fortuna tua! Ovviamente sto parlando di codice che è scritto in maniera molto diversa da quello scritto in altri contesti, ma che fa delle cose fantastiche e quindi per fortuna che c'è.

Se andiamo a un livello più basso o più alto, da che parte la guardiamo, la platea di persone che scrive le librerie secondo me non è molto cambiata.

Ovviamente fisicamente sì, sono 20 anni di differenza, persone che vent'anni fa non erano ancora nate, che adesso fanno i contributori di librerie sicuramente, ma stiamo parlando sempre di programmatori con un altro background rispetto ai data scientist.

Ci sono anche quelli che fanno il salto, conosco persone che hanno iniziato studiando chimica, fisica o altre biologia o altre scienze, hanno iniziato a programmare per fare data science e hanno scoperto che in realtà era quello per cui erano portati e che gli piaceva e hanno fatto il salto e si sono diventati programmatori, non solo data scientist.

Ne conosco alcuni che sono estremamente in gamma.

Hai detto una cosa molto interessante, io volevo buttarla in cacciara da povero idiota quale sono, però tu hai evidenziato un elemento che è discriminante, ne abbiamo già parlato quando parlammo di intelligenza artificiale e di codice scritto per far fare delle robe a machine learning e robe di questo tipo.

Il tipo di codice che si scrive è completamente diverso, è un codice che ha un'utilità con un altro concetto di mantenibilità e anche con un altro meccanismo di scrittura, forse anche più legato a un approccio discorsivo, rappresentativo, più da relazione che da sistema che devi mettere in piedi.

E qua entra in gioco il progetto, il prodotto nel quale lavori Anaconda che rivoluziona o comunque innova rispetto ai classici IDE per un mondo e un segmento specifico.

Esatto, allora in realtà Anaconda non è un'IDE, è una...

Mi piace quando mi correggi perché io dico stronzate.

Distinguiamo il prodotto Anaconda dalla compagnia Anaconda, perché Anaconda come compagnia fa anche altre cose tra cui appunto Pyscript, ma il motivo, il prodotto per cui è meglio conosciuta è appunto la distribuzione Anaconda che è esattamente una distribuzione di Python, quindi un modo per installare Python su dei sistemi, su dei computer, su delle macchine, alternativo a quello dei canali ufficiali, diciamo così, che però comporta tutta una serie di vantaggi, soprattutto nel settore della data science e è diventato nel corso degli anni de facto lo standard che io sappia quasi tutti i progetti seri, ma anche hobbistici, di data science usano Anaconda perché è il tool che risolve i loro problemi.

Sì, l'idea di avere proprio dei workbook, unire descrizioni, far girare direttamente all'interno del workbook il codice, io poi non lo conosco profondamente, quando ho provato Pandas però l'ho provato dentro Anaconda, devo essere sincero.

Esatto, ma secondo me tu adesso ti stai riferendo a Jupyter o Jupyter Lab o i Python notebooks che sono questo nuovo modo, sono anni che sono in giro, modo diverso di scrivere il codice in cui tu hai un notebook da browser e scrivi il codice e lo esegui in maniera interattiva potendo vedere grafici, tabelle e analisi di dati, ma questo non è Anaconda, questo è una parte di Anaconda, sono progetti che esistono al di fuori di Anaconda che semplicemente sono pacchettizzati in maniera tale da rendere banale e straightforward l'installazione anche ai non tecnici, ai non programmatori.

Quindi è proprio per quello che tu magari lo confondi, nel senso che tu installi Anaconda e ti trovi nel menu da far partire il notebook, da far partire l'IDE, l'editore eccetera ma in realtà quello che Anaconda ha fatto è stato semplicemente di prendere pezzi di, non pezzi, progetti già esistenti e molto utili e metterli tutti insieme in maniera tale che fosse facilissimo da usare.

Oltre a questo rende estremamente facile la possibilità di installare pacchetti di terze parti tra cui NumPy e tutto il Data Science Stack, soprattutto su Windows dove anni fa poter installare quelle estensioni era molto laborioso senza Anaconda.

Ok, adesso grazie per aver fatto un reframing perché in realtà come ti ho anticipato sono super nubo quindi adesso mi è più chiaro, anche in seno ad Anaconda è partito il progetto di PyScript, dico giusto? Esatto, è partito come idea più o meno proprio un anno fa, forse un po' meno di un anno fa.

È stato rilasciato al pubblico e fatto conoscere durante PyCon US, la conferenza negli Stati Uniti che si è tenuta da inizio aprile 2022, l'anno scorso, mi sembro di ricordare che fosse inizio aprile ma potrei sbagliarmi, metà aprile.

È super super super giovane quindi.

Sì, sì esatto.

Il progetto, in realtà alcune idee di fare una cosa del genere giravano già da quello che mi raccontano all'interno di Anaconda però poi a un certo punto hanno deciso di buttiamoci, proviamoci perché ci crediamo, crediamo che sia una cosa utile da fare, crediamo che ci possa essere mercato e domanda per questo tipo di tool, di software e si sono barra ci siamo perché io ho iniziato a lavorare per Anaconda il 4 di aprile, dopo pochi giorni abbiamo annunciato PyScript e ho iniziato a lavorare da subito su quello quindi sono anzi forse sono il secondo componente del team di PyScript ad essere stato assunto.

Per chi non lo sapesse ci puoi raccontare un po' di cosa si tratta? Allora sì, si collega molto bene a quello che stavamo dicendo poco fa ovvero Anaconda mette l'installazione di Python sul tuo computer in maniera facile e utilizzabile anche diciamo da non programmatori ma comunque è un entry barrier non indifferente perché se tu scrivi un programma in Python e lo vuoi far vedere a tua nonna o al grande pubblico e lo vuoi fare utilizzare non hai tantissime alternative, devi dire a loro di installarsi Anaconda o Python in altri modi, di installare tutte le librerie di cui hanno bisogno e eseguire il programma che tu gli mandi che è un file Python.

Ma capisci bene che questo non è gestibile come cosa, esistono dei modi per creare un eseguibile da programmi Python tipo PyInstaller eccetera eccetera ma comunque si tratta sempre di mandare un eseguibile a qualcuno che sarà di diversi megabyte di dimensione, quel qualcuno userà magari un altro sistema operativo quindi non riuscirà a eseguirlo eccetera eccetera eccetera.

Uno degli obiettivi non l'unico ma uno degli obiettivi di PyScript è abbattere questa barriera, rendere possibile usare Python e tutto l'ecosistema scientifico e non solo senza bisogno di aver nessun processo di installazione complicato e lo facciamo, il modo in cui riusciamo a farlo è eseguendo Python direttamente dentro il browser.

Quindi un'applicazione PyScript viene eseguita dentro un browser dal punto di vista dell'utente finale a un URL, ci clicchi sopra, apri un sito e si carica a PyScript.

Il codice Python viene eseguito client side, non server side, quindi è detta male ma per capirci al posto di JavaScript e questo significa che immediatamente tu nel momento in cui tu metti online la tua applicazione PyScript la puoi mandare link a chiunque e chiunque lo può eseguire sul loro browser di qualunque tipo di sistema operativo compresi device mobile e il gioco è fatto.

Questa è l'idea molto molto alla lontana di PyScript.

Io ho sbirciato, ho letto qualcosina di PyScript quindi adesso bleffo, ma sento puzza di WebAssembly.

Senti bene.

WebAssembly è la tecnologia alla base che rende possibile quello che ho appena descritto.

Cerchiamo di spiegare molto molto alla lontana in maniera veloce cos'è WebAssembly.

Da un certo punto di vista possiamo considerare una CPU virtuale con un suo instruction set che ha un emulatore all'interno di tutti i browser.

Quindi io posso scrivere dei programmi per questa CPU virtuale con delle istruzioni di basso livello, quindi istruzioni molto basso livello tipo leggi da questa zona di memoria, incrementa questo puntatore, scrivi 0 lì, somma questi due numeri eccetera eccetera, proprio esattamente come una CPU reale.

Il fatto che sia emulata o implementata dai browser la fa automaticamente diventare portabile perché io avendo un eseguibile compilato su WebAssembly posso eseguirlo dentro tutti i browser.

E' stato progettato in maniera tale da essere efficiente perché tutti i browser implementano WebAssembly in maniera tale da compilare il codice generico che entra, che è quello scritto dall'utente, compilarlo sulla CPU specifica del browser in questione e quindi farlo eseguire in maniera molto molto efficiente a livelli quasi comparabili a un programma nativo.

Ok, allora la mia domanda è, viene compilato, no ma il codice Python è interpretato, quindi adesso mi viene da dire che c'è Python dentro.

Esatto, quello che facciamo in PyScript è di utilizzare un'altra tecnologia, allora la tecnologia di basso livello è WebAssembly che abbiamo detto che è questa CPU virtuale efficiente e portabile.

Quello che è stato fatto è stato di prendersi Python e compilarlo, anziché per x86 o per ARM, compilarlo per WebAssembly.

Quindi tu ottieni un eseguibile che è python.wasm che puoi eseguire dentro il browser e con molti asterischi e avere il tuo Python dentro il browser che interpreta il tuo file.py esattamente come fassi Python sul tuo computer o sul tuo Mac.

Che versione di Python è compilata? Prima di andare, prima di proseguire, no no no, è il momento in cui cito qual è la tecnologia su cui noi ci basiamo, perché noi non abbiamo inventato questo mondo di Python dentro il browser.

Noi ci basiamo su un progetto che esiste già e si chiama Pyodide, che era nato in Seno a Mozilla anni fa, che è proprio Python compilato per WebAssembly.

Quindi già adesso, già prima di PyScript era possibile prendere Python, prendere Pyodide, metterlo dentro una web page e eseguire il codice Python in questa maniera qua.

Quello che PyScript punta a fare, quello che sta facendo, è rendere questo processo estremamente semplice e estremamente straightforward e basandosi su queste tecnologie di basso livello costruire una serie di piattaforme, di framework in modo tale che lo sviluppo vero e proprio poi alla fine sia banale o comunque molto molto semplice.

E' chiaro.

Mi ha chiesto la versione di Python, non ricordo, secondo me Pyodide al momento supporta la versione 3.10 di Python, 3.10.qualcosa, inizieremo a cercare di far funzionare anche la 3.11 prima o poi.

Così, senza...

magari sto per dire una fesseria e correggimi se sbaglio, ma siccome prima hai citato PyPy, no? Sì.

Il famoso JIT compiler e tutte ste robe.

Secondo te è possibile immaginare, e soprattutto è utile pensare, immaginare un PyPy compilato in WASM che con JIT aggiunge anche questo tipo di performance? È possibile e in parte il ruolo dei tamburi è già stato anche fatto in passato, ovvero non su WebAssembly ma anni fa c'era un progetto, che era un progetto di un contributore esterno, non era un core developer Py, si chiamava PyPy.js e questo progetto prendeva PyPy, lo compilava in JavaScript, adesso non ricordo se compilava su JavaScript plain o usando Asemble.js che era una versione limita di JavaScript che è il prepositore di WebAssembly e lo rendeva più veloce fondamentalmente.

E quindi tu avevi all'inizio un interprete PyPy che girava dentro il browser perché era stato compilato su JavaScript e questo progetto aveva aggiunto anche un back-end per il JIT compiler che metteva JavaScript a runtime, quindi effettivamente quello che tu stai dicendo esisteva, è stato fatto non su WebAssembly ma con JavaScript.

Quindi potenzialmente sì, potremmo rifare la stessa cosa per WebAssembly adesso.

Non è sui radar, secondo me, di sicuro non è sul mio radar, però magari qualcun altro ci sta pensando, perché torniamo al discorso di prima dei trade-off.

PyPy per poter essere così veloce e funzionare, avere JIT compiler, eccetera, ha un producere eseguibile che è molto più grosso di CPython.

E se stiamo parlando di web, significa che tutte le volte che vuoi eseguire il tuo programma Python su web, quindi il programma PyScript ad esempio, devi ricaricarti l'eseguibile di Python.

Ovviamente con un asterisco, perché poi il browser lo terrà in cache.

Però esiste quel tipo di problema e anche i tempi di startup su PyPy non sono ottimali.

PyPy è utilissimo e la sua nicchia principale è i programmi server-side che girano a lungo, perché il JIT compiler ha tempo di trovare tutti i pezzi di codice che sono eseguiti più spesso e compilarli in codice nativo e a quel punto, dopo un tot di secondi, di minuti di esecuzione, hai il tuo programma che va velocissimo.

Quindi io ho usato PyPy professionalmente nel corso degli anni, facevo consulente su queste cose qua, proprio in situazioni del genere.

Quindi programmi server-side che giravano 24 ore al giorno, 16 giorni su 7.

E in quel caso PyPy era eccezionale.

Se stiamo parlando di pagina web, significa che prima ancora che posso vedere l'Hello World, devo scaricarmi megabyte e megabyte di runtime, aspettare che JIT parta, che a quel punto sì, potrebbero esserci applicazioni per cui valla la pena, ma non diciamo che non è quello su cui ci stiamo concentrando adesso in PyScript.

Chiaro.

Quindi hai detto, se ho capito bene, fondamentalmente noi abbiamo una distribuzione di Python che gira su WebAssembly.

Esatto.

E poi abbiamo PyScript, l'ecosistema PyScript che fa, in qualche modo semplifica la comunicazione tra il mio codice Python, che in qualche modo sta sulla pagina, poi andiamo a vedere come e come la deve experience nella realizzazione, e il runtime che sta sotto.

Giusto? Giusto.

Come avviene la comunicazione tra lo snippet di codice Python che io embeddo nella pagina e il runtime? Sì, questo è esattamente il core di PyScript, quello che fa, che in realtà da un certo punto di vista, molto molto alla lontana, fa poco, si potrebbe anche dire.

Perché dal punto di vista utente, la pagina web, l'applicazione PyScript più semplice possibile, è un Hello World in cui io ho il mio codice HTML, nel tag head metto un tag script che punta un URL che contiene il codice di PyScript, scritto in JavaScript, ovviamente, perché questo è quello che capiscono i browser.

E questo codice di PyScript rende disponibile un nuovo tag dentro la pagina che è py-script.

Quindi a quel punto io posso scrivere dentro la pagina il mio codice Python dentro un tag PyScript e questo verrà eseguito in automatico nel momento in cui la pagina viene caricata.

Quindi la tua domanda è come fa il browser a sapere che deve eseguire questo codice, se ho capito bene? Giusto? Sì, quella è la prima parte, la domanda più la seconda viene subito dopo.

E quindi fondamentalmente quello che PyScript fa è un codice JavaScript che nel momento in cui fa il setup di un event handler che viene eseguito quando la pagina è finita di caricarsi, a quel punto attraversa il DOM della web page per cercare questi tag quando li trova li esegue.

Quindi li manda a Uluasm? Esatto, in sottofondo appena partiamo noi iniziamo a scaricare Pyodide perché abbiamo bisogno di Pyodide per poterlo eseguire.

Quindi è questa la parte che PyScript semplifica, anziché doverci preoccupare noi di scaricare Pyodide e scrivere le parti in JavaScript che servono per poterle istanziare e far partire, PyScript fa tutto in automatico.

Quindi quello che succede è che allo startup l'internet Pyodide viene scaricato e initializzato e poi buttiamo dentro il codice Python che troviamo dentro i tag.

Ti faccio una domanda, noi eseguiamo il codice Python dentro il browser però in realtà se non possiamo avere un feedback visivo del risultato dell'esecuzione del nostro codice probabilmente saremmo limitati, quindi immagino che in qualche modo PyScript abbia modo di comunicare con gli elementi del DOM per esempio.

Come avviene questo tipo di comunicazione? E questa è l'altra parte in cui PyScript si dimostra utile, perché noi puntiamo a semplificare il più possibile questo processo.

Quindi diciamo che se io voglio visualizzare qualcosa sulla pagina web abbiamo vari approcci.

Quello più low level è utilizzare Pyodide perché Pyodide permette di chiamare codici JavaScript.

Quindi nel momento in cui eseguo il mio codice Python dentro Pyodide io posso tranquillamente fare import JS e usare l'oggetto e il modulo JS per accedere a tutto il mondo JavaScript.

Quindi è assolutamente possibile fare JS.getElementById di pippo e ottengo un element e a quel punto posso eseguire tutte le operazioni sul DOM come eseguo in JavaScript.

Quindi questo è il modo low level di modificare una pagina web, esattamente come farei in JavaScript.

Però questo è utile per fare cose avanzate o fare determinati tipi di applicazioni, ma non è la cosa più semplice che puoi fare.

Quello che noi abbiamo fatto è stato di introdurre una nuova funzione che si chiama display che cerca di essere un print intelligente, capisce qual è l'oggetto che sto provando a visualizzare e fa il rendering più appropriato.

Quindi se tu fai display di un'immagine, di un oggetto immagine, lui visualizzerà un tag immagine dentro la HTML.

Se fai display di un grafico lui visualizzerà il grafico.

Se fai display di una tabella pandas potrai visualizzare la tabella formattata in maniera carina.

Ma tu gli dai il nodo dove attaccare sta roba o come funziona questa roba? Allora è configurabile, di default lui fa il display, cioè display visualizza un elemento nel posto dove c'è il tag.

Quindi diciamo come figlio, come fratello, del tag dove sono eseguito.

Ma esiste la possibilità di passare un argomento in cui gli dico qual è il target e quindi qual è l'id HTML del tag dove voglio visualizzare questa cosa qua.

Proprio collegandomi a questo ti faccio una domanda perché io vengo dal mondo full stack quindi anche framework front end.

C'è spazio per...

allora faccio un passo indietro.

Io riesco a immaginarmi il potenziale utente di questo tipo di tool.

Mi immagino per esempio il data scientist che vuole condividere in modo fatto bene i risultati e le ricerche in modo accessibile senza dover installare i tool e quant'altro.

E la mia domanda è c'è spazio per un potenziale web framework tarato però su questo tipo di utenza? Secondo me c'è spazio per tanti web framework tarati su quest'utenza e è proprio quello che noi cerchiamo di abilitare.

In javascript non hai un web framework, ne hai tanti e secondo gli use case ne usi uno piuttosto che l'altro e ne cresce uno nuovo ogni settimana, ogni mese da quello che è la mia percezione da Python.

Anche ogni giorno da utente di quel mondo.

In realtà anche Python è passato in quella fase perché parlavamo prima degli early 2000, nei primi anni 2000 c'era questa battuta che si faceva alle conferenze che nel tempo di un keynote almeno due o tre nuovi web framework spuntavano.

Perché ovviamente c'era un web framework server side, non client side, ma c'è stato il momento di esplosione web framework di Python.

Quello che noi puntiamo a fare, quello che a me piacerebbe che succedesse è che PyScript darà la possibilità di avere questa piattaforma di base che permette di eseguire codice Python in maniera facile, configurabile, efficiente, eccetera eccetera e on top di quello avere uno o più web framework non necessariamente fatti da noi.

Noi sicuramente prima o poi proveremo a scrivere qualche web framework per semplificare la vita agli utenti, ma mi aspetto che utenti di terze parti facciano altrettanto esattamente come è successo nel mondo JavaScript e come era successo nel mondo Python server side.

Io non lo so, lasciando libera la mente di divagare, mi viene in mente un'integrazione con D3JS per esempio, che in quel mondo ci starebbe tantissimo nel senso...

La buona notizia in questo caso è che tu già adesso puoi usare D3JS dentro PyScript, perché come dicevo prima, PyOdyte dà accesso al livello di JavaScript, quindi è assolutamente possibile usare D3 all'interno di Python.

E vale su PyScript.net slash examples, abbiamo vari esempi di casi d'uso e c'è anche quello che fa vedere come usare D3.

Ok, no, quello che ti dicevo è però, essendo PyScript nato proprio per colmare il gap o almeno rendere confidente l'utente strettamente collegato a Python ad altri ambienti, quindi immagino che ne so anche un certo livello di astrazione per l'utilizzo di D3, che potrebbe essere molto figo.

Quindi possiamo anche dirlo, se qualcuno ha voglia di sviluppare questi tool, lo spazio in questo modo, essendo un progetto molto giovane, c'è? C'è e secondo me è anche il momento giusto per fare questo disclaimer che potrebbe non essere ovvio a chi ci ascolta.

PyScript è un progetto nato dentro una conda, ma lo stiamo sviluppando e gestendo come un progetto fully open source, ma fully open source nel senso vero del termine.

Ci sono altri progetti, che sicuramente non voglio fare i nomi, ma progetti open source di facciata nel mondo, in cui sì, il codice è liberamente disponibile su GitHub, hanno rilasciato il codice open source, ma il modello di sviluppo della community non è per niente open, perché c'è un'azienda dietro che gestisce il progetto e ha l'ultima parola su tutto e ad esempio se tu vuoi fare una pull request devi essere approvata da un indipendente dell'azienda X.

Questi non sono progetti open, perché non permettono a nessuno a un esterno di diventare core developer o contributor, contributor sì, ma non allo stesso livello di quelli giusti tra virgolette.

In PyScript vogliamo assolutamente evitare questo.

È stata una cosa su cui io personalmente ho battuto molto nel momento in cui abbiamo iniziato a discutere di come gestire il progetto, eccetera, eccetera.

Proprio perché avevo esperienza passata con determinate situazioni, volevo che fosse il più open possibile e il più inclusivo e devo dire che eravamo tutti d'accordo, non è che ho dovuto combattere per ottenere questo.

Quindi la comunità di core developer di PyScript è assolutamente aperta a non-anacondiacs.

Ad esempio ne abbiamo già due che nei primi mesi di sviluppo hanno iniziato a fare molte pull requests, molti contributi alle discussioni su GitHub, eccetera, eccetera, e li abbiamo nominati core developer perché se lo sono ha meritato, come si fa normalmente nel progetto open source.

Quindi sì, se qualcuno vuole contribuire, lo spazio c'è, lo spazio c'è e siamo assolutamente aperti a questo tipo di collaborazioni e perché no, qualcuno se ha voglia e idee può assolutamente diventare core developer di PyScript.

Ad esempio abbiamo un server Discord su cui facciamo le nostre chat assolutamente in pubblico, abbiamo preso, nei primi mesi di Anaconda avevamo un canale sullo Slack interno di Anaconda dove si discuteva del progetto e poi a un certo punto abbiamo deciso di migrare su Discord e quel canale privato è stato cancellato.

Tutte le discussioni avvengono in pubblico perché è il modo giusto di gestire un progetto open source secondo me.

L'avere un'apertura di questo tipo probabilmente anche il turbo boost o comunque può dare un boost alla crescita del progetto che attualmente mi ricordi è in alpha no? No, allora la primissima versione che è stata rilasciata su PyCon era stata chiamata alpha, è ancora molto in divenire PyScript.

Tante decisioni di progetto, di design devono essere ancora prese, le stiamo ancora cambiando, le stiamo affinando, quindi sì, da un certo punto di vista possiamo considerare alpha ma dall'altro è anche stabile, nel senso che le cose che fa funzionano e le fa bene.

È importante dal punto di vista dodente finale usarla in maniera corretta, nel senso che dicevo prima tu devi includere un file javascript che è il motore di PyScript, è quello che contiene tutta la logica.

Di default uno può usare la versione latest, l'ultima versione disponibile di PyScript, ma significa che se il prossimo mese noi rilasciamo una versione di PyScript che ha dei breaking changes a quel punto la tua pagina web smette di funzionare, però è assolutamente possibile pinnare la versione e quindi dire dentro la pagina web di usare PyScript versione 2021.12.1 o quello che è.

E a quel punto quella pagina funzionerà per sempre, perché non cambierà il codice di PyScript.

Ho detto una cavolata perché ovviamente non era 2021.12 ma era 2022.12 perché è quella che abbiamo lasciato a dicembre.

Era chiaro il messaggio.

E adesso però ti faccio un'altra domanda.

Da persona che ha lavorato e lavora costantemente sul web vedo super importante la Dev Experience.

A livello di Dev Experience, magari se sto dicendo qualcosa che non va trattata perché è undisclosure, correggimi, però secondo me c'è un grosso spazio anche per eventuali estensioni dell'editor, dell'IDE.

Sì sì sicuramente.

C'è un IDE di riferimento ad oggi per lavorare su PyScript? Ad oggi diciamo che quello su cui ci siamo concentrati è stato scrivere le fondamenta, la parte a basso livello.

E quindi noi abbiamo questo codice che permette di eseguire i tuoi tag di PyScript usando tutte queste niceties di cui parlavo prima, la funzione display, il fatto che puoi cambiare versione, il fatto che puoi dichiarare in un tag apposta quali sono i pacchetti che vuoi installare in automatico vengono installati, quindi diventa tutto molto semplice usare anche NumPy e Pandas eccetera.

Però al momento la soluzione è scrivi un file HTML a mano e lo salvi su una qualche spazio web e quello è il tuo deployment di PyScript.

Sì, bisognerebbe fare un tool che renda possibile fare il raid più straightforward e cambiare e togliere questa entry barrier sicuramente, ma non è lo scopo del team di PyScript su questo, che è la versione di fondamenta di basso livello.

Forse è un po prematuro come… Prima o poi secondo me arriverà.

Chiaro, hai detto una cosa… Non è la mia personale preoccupazione, nel senso che non è il mio compito, io sono un compiler… Core developer… A me piace compiler e computer, quindi non sono il personale da cui chiedere un'idea.

Chiaro, scusa, però… Pensando ad Anaconda, il contesto secondo me ci starebbe a palla una cosa di questo tipo.

Hai parlato però di una cosa che mi ha acceso subito una lampadina, in parte hai già risposto, che era a questione di pendenze.

L'esperienza mia con Python, ne ho fatto due piccolissime, una dove ho provato NumPy e Pandas, dentro Anaconda tutto funzionava, va bene, tutto felice, bimboom.

L'altra è stata una lambda function e tipo prima di capire come embeddare le dipendenze, fare le cose, ho un po' pianto.

Per cui la domanda a cui pensavo è, tu hai detto io metto la dipendenza, quindi importo qualcosa, automaticamente la dipendenza viene giù.

Esatto.

E funziona, come funziona questa roba? Perché mi ha incuriosito.

Allora, dal punto di vista utente è la cosa più semplice del mondo.

Tu puoi mettere dentro la tua pagina web un tag py-config, dove puoi mettere varie opzioni di configurazione della tua pagina.

Una di queste opzioni è packages, quindi tu puoi fare packages uguale NumPy, Pandas, ApploadLib, e il codice di visualizzazione di PyScript si occupa di fare il resolving delle dipendenze, scaricarle e installarle in maniera virtuale all'interno della pagina web, in modo che siano poi disponibili dal codice che viene eseguito dopo.

Al momento questo è reso possibile grazie a Pyodide, perché Pyodide non è solo Cpython precompilato su WebAssembly, è anche un contenitore di pacchetti già precompilati su WebAssembly.

Quindi la distribuzione Pyodide comprende anche NumPy, Pandas e un sacco di altri pacchetti.

Quelli che non sono compresi dentro Pyodide in questo momento non sono utilizzabili.

Ma è sicuramente una cosa su cui stiamo lavorando e vogliamo lavorare, perché a me piacerebbe arrivare al punto in cui WebAssembly è una piattaforma di prima classe all'interno dell'ecosistema Python, in cui se io sono il sviluppatore di NumPy pubblico i miei compilati per Linux, per Windows, per Mac, per ARM, per x86 e per WebAssembly.

E a quel punto in automatico sono utilizzabili da chiunque le voglia utilizzare dentro il sistema.

Non ci siamo ancora, ma stiamo lavorando in quella direzione.

Questo perché in realtà molte librerie Python hanno sotto il cofano della roba CI, C++ simili? Esatto, è quello che dicevo prima, il problema è dell'estensione C.

Se tu hai del codice scritto in C devi compilarlo, che era il problema di PyPy all'epoca e è il problema di WebAssembly adesso.

Perché se è codice pure Python lo posso interpretare con l'interprete che ho già.

Se è estensione C devo compilarla a mano, che è anche il motivo per cui Anaconda ha avuto questo successo, perché come hai avuto modo di scoprire le tue spese, gestire le dipendenze non è banalissimo.

Quindi ovviamente Anaconda come compagnia ha l'esperienza di fare un package manager e di buildare pacchetti per WebAssembly, quello sicuramente, ma quello che puntiamo a fare, quello che secondo me la soluzione giusta è di lavorare con la community più larga di tutto il sistema Python.

Non deve essere una soluzione fatta da Anaconda per Anaconda, deve essere una soluzione per cui tutta la community Python decide di supportare WebAssembly.

E in questo senso le cose stanno andando bene, perché se Python ha già deciso che WebAssembly è una piattaforma supportata.

Proprio recentemente, qualche settimana fa, io ho fatto partire sul forum di Cpython, di Zoopatory, un paio di thread che puntano a far partire la discussione su cosa deve succedere per far sì che WebAssembly diventi una piattaforma di prima classe all'interno dell'ecosistema e quindi sì, c'è questo tipo di discussione.

Quanto ci vorrà non te lo so dire, però ad esempio ad aprile ci sarà la nuova PyCon di nuovo negli Stati Uniti e l'idea, non credo che sia ancora formalizzato, ma l'idea di avere un summit, un working group che raccoglie tutti i componenti Python, alcuni dei sviluppatori di vari progetti che hanno a che fare col mondo WebAssembly per cercare di discutere, di trovare soluzioni, di collaborare e andare tutti in una soluzione.

Sì e ti dirò di più, secondo me questo tipo di discussioni dovrebbero essere intavolati in più contesti e in più linguaggi perché WebAssembly di per sé è un game changer, ha rotto o sta rompendo o romperà il monopolio incontrastato di JavaScript nel front end per tanti anni.

Il vero è che comunque se tu vuoi interagire col browser anche con WebAssembly oggi hai bisogno di chiamare l'API attraverso JavaScript, però niente vieta ai browser di implementare in un futuro più o meno lontano dei binding direttamente? Penso che prima o poi ci si arriverà ma non è ancora dietro l'angolo perché WebAssembly è partito piccolo, diciamo così, hanno scelto un design, un modo di procedere che secondo me ha molto senso.

Sono partiti in piccolo facendo il minimo indispensabile di cose che potessero essere utili e fondamentalmente il WebAssembly come è adesso permette di compilare codici esistenti legacy non in maniera automatica perché la piattaforma è diversa da un Linux o un Windows 11, ci sono cose che bisogna sistemare ma diciamo che il 90% dei programmi compila senza problemi e bisogna sistemare un po' quel 10% di pezzi di codice che interagiscono in maniera tale che non è compatibile con WebAssembly e quindi permette di prendere programmi C e eseguirli all'interno di un mondo chiuso dentro il browser e già così è stata una rivoluzione perché se tu apri il browser adesso puoi usare Photoshop e AutoCAD dentro il browser e sono implementati così.

FFmpeg.

Esatto, hanno preso il codice gpp, l'hanno compilato su WebAssembly e funziona.

O padre o dadda.

Ma quello che poi stanno facendo adesso è di aggiungere feature e secondo me, da quello che è la mia percezione da esterno, è che stanno andando verso un mondo in cui WebAssembly diventerà la piattaforma di interoperabilità fra più linguaggi.

Quindi una delle feature di cui si sta discutendo e si sta lavorando per standardizzarla è quella del component model per cui sarà possibile dichiarare che un modulo WebAssembly implementa una certa interfaccia e utilizzarlo assieme a un altro modulo che consuma quell'interfaccia o di avere oggetti più ad alto livello perché al momento tu dai per WebAssembly puoi passare solo numeri, perché separa numeri e quello è, ma quindi arriverà il momento in cui tu potrai passare un oggetto dentro WebAssembly e chiamare dei metodi su questo oggetto che viene dato dall'esterno e nel momento in cui noi abbiamo queste funzionalità il passo successivo, non so se quanto è breve, ma è la strada tracciata per avere dei component model che ti espongono al DOM e a quel punto tu potrai cambiare il DOM e interagire con il browser da dentro WebAssembly senza passare per JavaScript.

Ma questa è una mia personale elucubrazione che non so, però secondo me stiamo andando in quella direzione lì.

Ti dico la mia allora che è ancora più estrema nel senso che in realtà il browser sta di per sé diventando un piccolo sistema operativo e questo però nel contempo ritriggera una preoccupazione che gli ascoltatori di Gitbar già conoscono che è quello di aggiungere un livello di complessità a tutto lo stack, un livello intermedio a tutto lo stack.

Allora sì però non dimentichiamo che WebAssembly non è solo browser perché esiste tutto un ecosistema di WebAssembly sul lato server ovvero che utilizza tutta questa funzionalità e tutte queste feature senza doverle usare dentro un browser.

Quali sono queste funzionalità? La possibilità di avere il codice portabile, la possibilità di avere il codice sandboxed che quindi io posso eseguire il codice arbitrario dato da terzi ed essere sicuro che non può inficiare il mio sistema perché l'esecuzione è sandboxata e questo apre un mondo nuovo perché esistono già dei sistemi che permettono di caricare dei moduli WebAssembly ed eseguirli sui server senza problemi di sicurezza, senza preoccupazioni di tipo di sicurezza e quindi fondamentalmente è una versione lightweight dei container che a loro volta era una versione lightweight delle virtual machine e quindi stiamo andando in quella direzione lì.

Quindi WebAssembly sarà importante anche senza il browser secondo me.

Ha senso.

Ultima domanda perché vedo che il tempo vola siamo già oltre a un'ora, magari è una domanda stupida e non ha senso, però rischi per la sicurezza? Nessuno con un asterisco.

L'asterisco è che essendo software ci può sempre essere un baco e quindi se la mia virtual machine, la mia sandbox è bacata, un attaccante può sfruttare questo baco di sicurezza per farlo esplodere.

E quello vale sempre, ma vale per WebAssembly come vale per JavaScript, come vale per la JVM, come vale per i container, per le virtual machine, per VMware, qualunque cosa.

Detto questo, di default WebAssembly è sicuro perché hanno fatto una scelta molto precisa e molto sensata ovvero di non permettere l'accesso a nessun tipo di risorsa esterna per default.

A livello tecnico quello che fa WebAssembly è di darti questo instruction set che puoi usare per fare computazioni, calcolare numeri, andare avanti finché si vuole, ma quello che puoi fare è continuare a fare un loop e eseguire le soluzioni.

Non c'è modo di chiamare system call, non c'è modo di accedere al file system, non c'è modo di chiamare funzioni di librerie esterne a meno che non le passiamo noi esplicitamente.

Quindi a livello tecnico ogni modulo WebAssembly ha una serie di import e di export, che sono funzioni che importo e che esporto ovviamente, e quindi ad esempio funzioni di import potrebbero essere apri questo file, ma a questo punto il file non necessariamente è nel mio file system su disco, è un file system virtuale che io sandbox decido di esportare.

Quindi nel momento in cui l'environment è sicuro io posso eseguire codice arbitrario WebAssembly senza problemi per sicurezza.

Ovviamente se io negli import gli do una funzione che permette di eseguire codice arbitrario sul mio computer siamo a punta caro, però di default è stato progettato molto bene da questo punto di vista.

Qui è una domanda che tanti ci fanno su PyScript, ci dicono è non sicuro perché posso leggere i file eccetera, no, è tanto sicuro quanto JavaScript, cioè il codice Python dentro PyScript non può fare nulla di più di quello che può fare il codice JavaScript dentro il browser.

E che non significa che sia sicuro al 100% perché esistono exploit JavaScript, esistono problemi di cross scripting, leaking di cookie eccetera eccetera, ma sono gli stessi che abbiamo con JavaScript e le abbiamo anche dentro Python, non di più.

Chiaro, chiaro.

Beh adesso devo dire che dall'inizio della puntata ad adesso una visione un pochino più chiara ce l'ho e quindi ti ringrazio.

Tu ti sgrazie ma quando ho iniziato a lavorare su queste cose qua, ormai nove mesi fa, avevo la stessa visione che mi ritualizzo questa puntata.

Guarda, di WebAssembly ci ho visto solo un paio di robe perché sto studiando Rust e siccome vengo dal mondo web uno dei modi per utilizzarlo in modo intelligente è quello, per dirti, in WebAssembly ci sto facendo una roba che mi calcola la waveform di un mp3 di un'ora e mezzo, sempre per il podcast, fatto in JavaScript ci mette un minuto e qualcosa, la roba in WASM ci mette qualche decina, una decina di secondi.

È il tipo di operazione perfetta per WebAssembly.

Ecco, la mia conoscenza di WebAssembly inizia là e finisce là, ancora non gira perfettamente quindi però mi ha super fatto piacere aprire questa porta verso questo mondo anche perché è un mondo, quello di PyScript, molto lontano dal mondo dove mi trovo quindi è sempre mia incuriosità ha catturato l'attenzione così come ha catturato l'attenzione di molti membri della community che ne hanno parlato a lungo, da quando c'è stata la presentazione a oggi se ne ha parlato diverse volte di PyScript nel nostro nel nostro gruppo quindi è anche termometro del fatto dell'interesse che gira attorno a questo progetto e che senza dubbio in qualche modo sono sicuro ci stupirà e sai perché? Perché va dal mio punto di vista a colmare, sai, ti ho detto che mia moglie fa il Data Engineer e quindi io vedo spesso che esiste un intermediario che utilizza tool come Qlik o Tableau per la visualizzazione dei risultati di computazione, avere un tool agnostico al di là di questo tipo di prodotti commerciali, avere un tool agnostico che ti permette di fare qualcosa handmade, non solo l'output di visualizzazioni già pre-made o con dei parametri, per me da sviluppatore ti può apre dei cancelli.

Infatti è un'unica notice case, PyScript secondo me può essere tante cose a seconda di come lo vedi, a seconda di cosa decideremo di priorizzare e di quale funzionalità offrire e quali no, però di sicuro il Data Scientist che vuole pubblicare la propria applicazione o i risultati, una grafica interattiva online in maniera che sia facile da scrivere e facile da eseguire, visualizzare per gli utenti, quello è un nostro use case da subito.

L'altro grosso use case su cui ci vogliamo concentrare di sicuro è l'education, quindi scrivere di tutto il più semplice possibile in modo tale che sia possibile eseguire Python, imparare Python, imparare a programmare anche senza avere un entry barrier molto molto basso.

E qui ci colleghiamo al discorso che ci ho detto prima, certo ci vuole un IDE, ci vuole un modo facile per scrivere queste cose qua, ma non è quello di cui mi occupo io personalmente.

LM.

Comunque è un progetto giovanissimo, quindi magari sai cosa facciamo Antonio? Ci diamo appuntamento tra un anno e mezzo, due anni e ci porti qualche aggiornamento se ti va? AC.

Volentieri, volentieri.

LM.

Allora io direi che vista l'ora è il momento del Paese dei Balocchi, il momento nel quale condividiamo qualcosa che ha catturato la nostra attenzione che può essere un libro, uno script, un qualunque cosa insomma possa valer la pena essere condivisa nella nostra community.

Per cui la mia domanda Antonio è, hai qualcosa da condividere con noi? AC.

E conduco nel Paese dei Balocchi.

LM.

Ah, il Paese dei Balocchi.

AC.

Sì, per fortuna mi avevi già detto prima, in anticipazione che avevo l'occupa di pensarci, perché se no su due piedi avrei fatto la figura.

Allora, visto che abbiamo parlato di WebAssembly, e visto che abbiamo fatto quel discorso, per cui nove mesi fa io ne sapevo poco e nulla di questa tecnologia qua, e anzi anche ero un po' scettico se devo dire la verità, appena ho iniziato a sentire pareste cose qua non mi quadrava, quello che ho fatto è stato di comprarmi un libro e leggerlo.

Un libro che non è neanche grosso, saranno 200 pagine se non ti so dire, della O'Reilly, WebAssembly The Definitive Guide, e mi ha aperto gli occhi, perché è scritto molto bene, è più una panoramica che un in-depth.

Parte dalle basi, parte da scrivere codici WebAssembly a mano e eseguirlo, fino a utilizzare altri linguaggi per compilare su WebAssembly e usi più avanzati, ma soprattutto mi è stato molto utile per avere una visione su un'understanding su quello che è la direzione in cui WebAssembly sta andando.

Quindi se qualcuno è interessato all'argomento è un libro che sicuramente mi sento di consigliare.

Assolutamente, e aggiunto alla mia lista di libri da leggere, perché un episodio a settimana, anzi oggi siamo in pochi, ma ci sono episodi in tre o quattro, e buona parte dei balocchi sono libri, alla fine la mia coda di lettura è abbastanza lunga.

Comunque è super interessante, specie nel contesto che sto studiando adesso, come ho detto prima, sto provando a dare uno sguardo su Rust, in modo con risultati mediocre, poco convincenti, ma sono ostinato, quindi prima o poi riuscirò a tirarne fuori qualcosa.

Quindi WebAssembly è un modo per portarlo nell'ecosistema dove vivo e dove lavoro tutti i giorni.

In questo periodo ho una certa attrazione per quanto riguarda il mondo dei protocolli.

C'è un certo interesse verso questo ecosistema e ho voluto unire le due cose, quindi ho cercato un po' di materiale per come implementare una distributed hash map in Rust o fare così questo tipo.

Forse chiedevo troppo a me stesso, ma sono finito in un canale YouTube, si chiama Geek Lunch, che ha una playlist di video molto molto interessante, al di là poi del contenuto, che è la creazione di una piccola blockchain, abbastanza naive come implementazione, però di una piccola blockchain in Rust.

Non sto qua a dipanarvi le mie bold opinion verso il mondo delle blockchain, però è comunque interessante capire come funziona e vederlo in Rust unisce i due mondi.

Vi metto il link perché è spiegata molto bene, ne è affrontata la visione dello sviluppatore, cosa che insomma quando si parla di blockchain poco si si osserva, perché si guarda sempre la visione un po' finanziaria, un po' cosa ci possiamo inventare on top, quando invece se noi guardiamo il protocollo è veramente figo.

Poi al di là delle implementazioni se vestiamo i panni dello sviluppatore, quindi ho già parlato anche troppo di questo canale YouTube, di questa playlist, io ve la metto nelle note dell'episodio e poi fatemi sapere cosa ne pensate nel gruppo Telegram.

Antonio io ti ringrazio infinitamente per essere venuto a trovarci, grazie davvero e complimenti per il lavoro che… scusa non ti ho sentito perdonami.

Grazie a te di avermi invitato.

Guarda il piacere è stato tutto tutto mio perché grazie a te abbiamo aperto una porta che insomma volevo aprire da un po' di tempo dentro il Gitbar per vedere cosa ci sta sotto.

Io rinnovo l'invito quando hai delle novità o quando hai qualcosa da condividere con noi pingami pure perché da oggi Gitbar è un po' anche casa tua, quindi quando ti va di bere una birra fresca con noi ahimè è virtuale, pingami pure.

Faccio una controproposta visto che a fine maggio mi sembra sarò a Firenze per Pi con Italy, chi viene facciamo una Gitbar birra.

Ah beh qua mi tenti, in realtà so che molti membri della community, abbiamo una fetta anche importante della community piatonista, della community di Gitbar che sono piatonisti e vedrò se riesco a venire giù anch'io, non sono proprio vicinissimo però… Tu conta che viva a Berlino quindi è proprio… Sì in realtà io a Lione quindi… Ah ok allora ce la richiamo.

Un ringraziamento enorme Antonio, grazie davvero e a quel punto alla Pi con se riuscirò a venire avrò modo di offrirti questa birra reale che solo oggi ti offro in modo virtuale.

La ragazzia mi ha dato a spendere una conta, però spero che il mio manager non ascolti questa parte.

Grazie, grazie mille, alla prossima.

Ciao a tutti.

Gitbar, il circolo dei full stack developer.

Una volta a settimana ci troviamo davanti a due birre e con BrinReppo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei full stack dev..