Bene e benvenuti su GIT BAR, 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 è accurato due cose che sono state nella bocca di molti, nel senso che se ne è parlato parecchio e oggi è qua Gitbar per parlarne anche con noi, ma prima di svelarvi chi è, intanto non ve lo dico e non ve lo dico almeno prima di avervi ricordato i nostri contatti, info@gitbar.it @brainrepo 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 hai stato anche core developer di Pypy, hai lavorato e stai lavorando sul nuovo progetto Hpy, giusto Antonio? Ho detto bene? Hai detto bene, Hpy in realtà.Sapi che io sto tipo dicendo sigle a caso perché sono completamente nubo del mondo Python? Credo aveva 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 ci metto la lettera PAI in fondo quindi i prossimi progetti sarà lettera a cavo e PAI.Dimmi una cosa, allora per quanto riguarda PAI PAI è stato il tuo precedente progetto giusto? Sì in realtà sono ancora formalmente Core Development di PyPy, anche se ultimamente, oggettivamente, ho lavorato poco su PyPy da un paio di anni perché appunto mi sono dedicato su Hpy che è da un certo punto di vista uno spin off e quindi tutto il mio lavoro che ho fatto su PyPy negli ultimi due o tre anni è stato mirato a supportare Hpy.Domanda, abbiamo detto PyPy e Hpy, per chi non conoscesse il mondo Python di cosa si tratta? Allora abbiamo...cerco di sintetizzare...Ho aperto il vaso di Pandora! Allora PyPy è 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 eseguito dall'interprete Python, che quello di default è chiamato CPython, che sta per Classical Python o Python scritto in C.PyPy è un'implementazione alternativa, ovvero un altro programma, che da command line si chiama PyPy, che prende il tuo sorgente, il codice sorgente scritto in Python, e lo esegue, e uno dice "Va beh, perché dovrei?" Il punto di PyPy è essere più veloce, perché usa tecniche anche relativamente avanzate compilazione just in time per cui alla fine riesce a tenere performance migliore di quelle che hai con Cpython.In determinati casi, con determinati trade off, ci sono dei casi d'uso in cui Pypy è un'ottima soluzione, degli altri in cui non serve o non è così utile, però l'obiettivo principale il principale di PyPy 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 da kill principale di PyPy che sono le estensioni scritte in C, le C-extensions di CPython, perché quando tu installi una libreria in Python con pip install o con un non 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 espressioni 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.NumPy, grosse parti di SciPy, grosse parti di Pandas, PyTorch, scritto in C++, comunque tutto quell'ecosystem lì è scritto in C.Queste esenzioni, 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 C Python developer, che è includepython.h.Chiunque ha scritto in estensione C inizia il suo sorgente con includepython.h in C.Il problema è che questa API è estremamente tied, adesso mi viene in italiano, ma accoppiata, bravo, ai dettagli interni di C Python.Quindi significa che per un interpreter alternativo che usa dei dettagli implementativi diversi diventa veramente difficile poterlo implementare in maniera efficiente.PyPy supporta le C-extensions in maniera quasi totale, cioè quindi su PyPy si possono usare NumPy, SciPy, eccetera, ma visto che dobbiamo emulare il comportamento di C Python, vanno molto più lenti di quello che dovrebbero e potrebbero.Quindi tendenzialmente un programma PiPi, eseguito al suodo PiPi, è molto molto veloce nelle parti pure Python e molto più lento, o un po' più lento, nelle parti scritte in C delle C-Extensions.HPI è 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-Extensions 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 se Python 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 sulle JVM.Quindi Hpy è utile anche per loro.Questa è l'estrema sintesi.Ti faccio una domanda perché adesso mi sorge proprio il dubbio, o comunque la curiosità.Hai già citato tre implementazioni diverse di Python, no? Il fatto che ci siano più implementazioni del non so del run time 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 e secondo me sottolinea la salute della comunità Python.Quasi tutti i linguaggi di cui ho una conoscenza quando hanno avuto successo hanno avuto altre implementazioni.Perché? Perché quando tu implementi un linguaggio soprattutto dal alto livello sei sempre costretto a fare dei trade-off.Può essere maggiore efficienza o maggiore semplicità nel scrivere il codice, minore 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 pi, a quel punto non mi serve, oppure serve solo una piccola fetta.Se tante cose non le posso usare, le posso usare ma vanno lenti eccetera eccetera, non 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 su JVM, adesso ne abbiamo un altro appunto, Iron Python, che era Python per .NET, abbiamo appunto PyPy, che supporta varie architetture, questi direi che sono i principali, ma probabilmente me ne dimentico alcuni, quelle che erano diciamo complete.Poi 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 un Laden Swallow, che era stato...mi sembra che fosse uscito nel 2007/2008 dai Google Labs.Recentemente c'è questo piston, scritto con la Y, che continua a essere supportato, ma che io sappia sviluppato meno attivamente di prima.Bene, sto sicuramente dimenticando qualcuno, ma nessuno ha avuto, neanche lontanamente, il successo che ha avuto c'è Python.parlando di 99% a 1% o cifre anche minore di questa.LM: chiaro.A proposito di successo e 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.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, 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 fatto 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 informatica 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.Vedo anche confrontandomi con i suoi colleghi, con l'ecosistema di cui fa parte, e 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, NumPy, Pandas e quant'altro.Quindi alla fine probabilmente neanche hanno comtezza 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 questo nuovo platea di utilizzatori che è sicuramente molto diverso da quello che c'era nel 2001, ma anche nel 2010.Nel contempo, non lo so, adesso sto lasciando la mente libera di vagare anche di dire stronzate quindi 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 un po' diluita, perché hai figure diverse, con competenze diverse che scrivono codice.Come ha reagito la community dei "vecchi pythonisti" all'arrivo di questo nuovo codice? E soprattutto c'è stata un'apertura? LM: E' una domanda molto complessa a cui faccio fatica a rispondere in generale.Secondo noi 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 fatto dai data science.Sì può capitare, ma in generale non è quello che mi passa.Per fortuna tua.Ovviamente stiamo 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ù alta, seguendo da che parte la guardiamo.La platea di persone che scrive le librerie, secondo me, non è molto cambiata.Ovviamente, fisicamente sì.Siamo 20 anni in differenza di persone che 20 anni fa non erano ancora nate e che adesso fanno i contributor di librerie, sicuramente.Ma stiamo parlando sempre di programmatori con un altro background rispetto 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 ne conosco alcuni che sono estremamente in gamma.LM: 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 parlamo 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, non vorrei dire una fesseria, ma 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 idee per un mondo e un segmento segmento specifico, no? Esatto, sì.Allora in realtà Anaconda non è un'idea, è una...Ecco, vai vai, 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.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, no sono anni che sono in giro, modo diverso di editare e 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, questa è una parte di Anaconda, sono progetti che esistono al di fuori di Anaconda, che semplicemente sono pacchettizzati in maniera tale da rendere banale e straight forward 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'editor eccetera 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.In seno ad Anaconda è partito il progetto di PyScript? 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.LM: è super super super giovane, quindi.ACQ: 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 sì, a un certo punto hanno deciso di buttarci, provarci, 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 PyScrita e ho iniziato a lavorare da subito su quello, quindi forse sono il secondo componente del team di PyScrita a 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 permette 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à diversi megabyte di dimensione, qualcuno userà magari un altro sistema operativo quindi non riuscirà a eseguirlo eccetera eccetera eccetera eccetera.Uno degli obiettivi, non l'unico, uno degli obiettivi di PyScript è abbattere questa barriera, rendere possibile usare Python e tutto l'ecosistema scientifico e non solo senza bisogno di avere nessun processo di l'installazione è complicata.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, ad 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, 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.Diciamo questa è l'idea molto molto alla lontana di PyScript.Io ho sbirciato ho sbriciato, 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 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, diciamo così 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 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.LM: Che versione di Python è compilata? Prima di andare, prima di proseguire, è il momento in cui cito qual è la tecnologia su cui noi ci basiamo, perché noi non abbiamo inventato questo mondo di Python dentro browser, noi ci basiamo su un progetto che vi dite già, 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 PyDial, 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.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 Pyoday dal momento supporta la versione 3.10 di Python, 3.10.qualcosa, inizieremo a cercare di far funzionare anche la 3.11 prima o poi.LM: Così, senza… magari sto per dire una fesseria e correggimi se sbaglio, ma siccome prima hai citato PyPy, il famoso JIT compiler e tutte ste robe, secondo te è possibile immaginare, e soprattutto è utile pensare, immaginare un Pi Pi 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 esisteva un progetto che era un un progetto di un contributore esterno, non era ancora davvero Pi, si chiamava PiPi.js e questo progetto prendeva PiPi, lo compilava in JavaScript, adesso non ricordo se compilava su JavaScript plain o usando Asemble.js, che era una versione limited di JavaScript, che è il prepositore di WebAssembly e lo rendeva più veloce fondamentalmente, e quindi tu Tu avevi all'inizio un interpreter PiPi 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 e è 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 produzione 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.PiPi è 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 PiPi 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, a 16 giorni su 7.E in quel caso PiPi 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.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ì, 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 "py-script" e questo verrà eseguito in automatico nel momento in cui la pagina viene caricata.Quindi la tua domanda è il browser a sapere che deve eseguire questo codice, se ho capito bene, giusto? Sì, quella è la prima parte, 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 attraverso 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 Pesquil semplifica.Anziché doverci preoccupare noi di scaricare PyOdied 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'interprete PyOdied viene scaricato e initializzato e poi buttiamo dentro il codice python che troviamo dentro il 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, 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 faressi 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 il display di un grafico, lui visualizzerà il grafico se fai il display di una tabella pandas, potrai visualizzare la tabella formatata 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è il display visualizza un elemento nel posto dove c'è il tag, quindi diciamo come figlio, come fratello, scusate, 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 tool e quant'altro.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 questa 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.Ovviamente era un web framework server side, non client side, ma c'è stato il momento di esplosione del web framework di Python.Quello che noi puntiamo 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, straightforward, 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 altrettante, esattamente come è successo nel mondo JavaScript e come era successo nel mondo Python Server Side.Io non lo sto 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 Pyodide da accesso al livello di JavaScript quindi è assolutamente possibile usare D3 all'interno di Python e vai su pyscript.net/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 da strazione 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 mondo, 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.Vice Crypto è 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 non voglio fare i nomi, ma progetti open source di facciata nel mondo, in cui il codice è liberamente disponibile su GitHub, hanno lasciato 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 deve 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 di serie B, non allo stesso livello di quelli "giusti".In PyScript vogliamo assolutamente evitare questo.È stata una cosa su cui io personalmente ho battuto molto nel momento in cui abbiamo ho 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 Payscript è assolutamente aperta a non-anacondiacs Ad esempio ne abbiamo già due che nei primi mesi di sviluppo hanno iniziato a fare molte pull request, molti contributi alle discussioni su GitHub, eccetera, eccetera, e le abbiamo nominati core developer, se lo sono meritato, come si fa normalmente nel progetto open source.Quindi sì, se qualcuno vuole contribuire, lo spazio c'è.Lo Spezia CI siamo assolutamente aperti a questo tipo di collaborazioni 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.Compresi nei primi mesi di Anaconda, avevamo un canale sullo Slack interno di Anaconda dove si discuteva del progetto e poi 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 project 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, attualmente, mi ricordi, è in alfa, no? No, allora, la primissima versione che è stata rilasciata su PyCon era stata chiamata alfa.È 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 alfa, ma dall'altro è anche è stabile, nel senso che le cose che fa funzionano e le fa bene.È importante, dal punto di vista d'udiente 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.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 dei 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.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ì, sicuramente.C'è un'idea di riferimento ad oggi per lavorare su PyScript? No, 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 pi script usando tutte queste queste nice things di cui parlavo prima la funzione display il fatto che puoi cambiare versione e 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, pandas eccetera però al momento la soluzione è scrivi un file HTML a a mano e lo salvi su una qualche spazio web è quello il tuo deployment di PyScript.Sì, bisognerebbe fare un tool che renda possibile fare il...rede più straightforward e cambiare e togliere questa entry barrier, sicuramente, ma non è è lo scopo del team di PyScript su cui sto lavorando, che è la versione fondamentale di basso livello.LM: forse è un po' prematuro come… LM: prima o poi, secondo me arriverà.LM: chiaro.Non è la mia personale preoccupazione, nel senso che non è il mio compito, io sono un compiler, a me piace compiler e just compile, quindi non sono il personale a cui chiedo di unire.Chiaro, scusa.No, però è una domanda assolutamente recita.Sai, 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 subito una lampadina in parte hai già risposta che era a questione di pendenze no? Io tipo l'esperienza mia con python ne ho fatto due piccolissime una dove ho provato non pay e pandas dentro una conda tutto funzionava va bene bello tutto felice 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 import qualcosa, automaticamente la dipendenza viene giù 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 dove puoi mettere varie opzioni di configurazione della tua pagina una di queste opzioni è "packages" quindi tu puoi fare "packages=numpy,pandas,matplotlib" e il codice di visualizzazione di PyScript si occupa di fare il resolving delle dipendenze e 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 C Python compilato 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 Pyodire 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 una piattaforma di prima classe all'interno dell'ecosistema Python in cui, se io sono il sviluppatore di NumPy, pubblico 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 li voglia utilizzare dentro il browser.Non ci siamo ancora ma stiamo lavorando in quella direzione.Questo perché in realtà molte librerie Python hanno sotto il cofano della roba CI, CPU simili? Esatto, è quello che dicevo prima, il problema è l'estensione C.Se tu hai del codice scritto in C devi compilarlo.che era il problema di PiPi all'epoca e è il problema di WebAssembly adesso, perché se è codice pure Python lo posso interpretare con l'interprete che ho già.Se è scansione ci 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, e 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.Io ho visto una soluzione per cui tutta la community Python decide di supportare WebAssembly e in questo senso le cose stanno andando bene perché CPython ha già deciso che WebAssembly è una piattaforma supportata.Proprio recentemente, qualche settimana fa, io ho fatto partire sul forum di CPython, gli sviluppatori, un paio di thread che puntano a rendere WebAssembly, 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à il nuovo PyCon, il 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 in tutta una stessa direzione.Sì e ti dirò di più, secondo me questo tipo di discussioni dovrebbero essere intavolati 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.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 i codici esistenti legacy, non in maniera automatica perché la piattaforma è diversa da un Linux o un Windows, quindi ci sono cose che bisogna sistemare, ma diciamo che il 90% dei programmi con pila 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 browser e sono implementati su webassembly.com.FFmpeg Esatto, hanno preso il codice gpp, l'hanno compilato su webassembly e funziona.O padre o dai.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 e puoi passare solo i numeri, perché siamo animatori e i numeri è 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 questa 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 nome tra G-Logo e browser da G-Logo e WebAssist senza passare per JavaScript.Ma questa è una mia personale recuperazione 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 una mia preoccupazione che gli ascoltatori di github già conoscono che è quello di aggiungere un livello di complessità a tutto lo stack, un livello intermedio a tutto lo stack.E' qua! Allora sì però non dimentichiamo che WebAssembly non è solo browser perché esiste tutto un ecosistema di WebAssembly sul lato server ovvero che utilizza tutte queste funzionalità e tutte queste feature senza doverle usare dentro un browser.Sì, vero.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ì e 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 è baccata, un attaccante può sfruttare questo bacco di sicurezza per fare un XBlock.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 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 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 codici arbitrari WebAssembly senza problemi per sicurezza ovviamente se io negli import gli do una funzione che permette di eseguire codice arbitrarie sul mio computer, siamo a punta capo.È ovvio, sì, chiaro.Di default è stato progettato molto bene da questo punto di vista.E' una domanda che tanti ci fanno su PyScript.Ci dicono "eh ma è non sicuro perché posso leggere i file" eccetera.No, è tanto sicuro quanto JavaScript.Cioè il codice Python dentro a PyScript non può fare nulla di più di quello che può fare il codice JavaScript dentro al browser.e che non significa che sia sicuro al 100% perché esistono esplorazioni a JavaScript, esistono problemi di cross scripting, leaking di cookie eccetera eccetera, ma sono gli stessi che abbiamo con JavaScript e li abbiamo anche dentro Python, non di più.LM: 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 scherzi ma quando ho iniziato a lavorare su queste cose qua, ormai nove mesi fa, avevo la stessa visione che mi ritualizza 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 composizione perfetta per WebAssembly? 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 PiScript 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 è uno dei nostri use case.Per me può essere tante cose a seconda di come lo vedi, a seconda di cosa decideremo di priorizzare e di quali 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 concentrarvi sicuro è l'education, quindi e di tutto il più semplice possibile in modo tale che sia possibile eseguire Python, imparare Python, imparare a programmare anche senza appunto avere un entry barrier molto molto bassa.E qui ci colleghiamo alle scelte che ci hai 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.Comunque è un progetto giovanissimo.Quindi, sai cosa facciamo Antonio? Ci diamo appuntamento tra un anno e mezzo, due anni e ci porti qualche aggiornamento se ti va? Volentieri, volentieri.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? E con tu con il paese dei balocchi! Ah il paese dei balocchi! Sì, per fortuna che mi avevi già detto prima, in anticipazione che non avrei avuto tempo di pensarci, perché se no su due piedi avrei fatto la figura.Allora, visto che abbiamo parlato di WebAssembly e visto che abbiamo fatto quei discorsi, 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 parlare di queste 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, 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 WebmasterBee sta andando.Quindi se qualcuno è interessato all'argomento è un libro che sicuramente mi sento di consigliare.LM: Assolutamente, è aggiunto alla mia lista di libri da leggere.Un episodio a settimana, anzi oggi siamo in pochi, ma ci sono episodi in tre, in 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 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 e quindi WebAssembly è un modo per portarlo nell'ecosistema dove vivo e dove lavoro tutti i giorni e 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 un po' di materiale per come implementare una distributed dash 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 Unisce i due mondi quindi 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 delle 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 insomma 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 dentro il github 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 Pai con Italy, chi viene facciamo una Gitbar Beer.Ah beh, qua mi tenti, in realtà so che molti membri della community, abbiamo una fetta anche importante della community Paitunista, della community di Gitbar che sono Paitunisti e vedrò se riesco a venire giù anch'io, non sono proprio vicinissimo però...Tu conta che io vivo a Berlino, quindi è proprio l'iniziato l'idea.Sì, in realtà io a Lione, quindi insomma.Ah ok, allora ce la rischiamo.Esatto.Un ringraziamento enorme Antonio, grazie davvero.E a quel punto alla Paikon, se riuscirò a venire, avrò modo di offrirti questa birra reale che solo oggi ti offro in modo virtuale.e mi hanno dato a spendere una conda.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 Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dead.
