Dopo ben 4 anni di successi (si sono toccate punte di 400 partecipanti) PyCon Italia ha ceduto temporaneamente il posto alla più prestigiosa EuroPython, evento internazionale svoltosi fra il 20 e il 26 (in realtà gli ultimi due giorni erano riservati agli “sprint”, ma ne parlerò meglio dopo), che si ritroverà a Firenze anche il prossimo anno.
Con circa 650 partecipanti e ben 7 tracce (di cui una in lingua italiana, omaggio alla nostrana PyCon, seconda soltanto all’EuroPython per affluenza nel continente) potete ben capire come sia stato molto difficile annoiarsi. La carne al fuoco era così tanta che a volte decidere quale talk seguire è stato un dilemma, sacrificando necessariamente qualcosa d’interessante.
Come ogni anno tutti gli interventi sono stati videoregistrati, per cui è sempre possibile recuperare quello che s’è perso. Rispetto a prima c’è da dire che i video sono stati messi a disposizione in tempi rapidissimi. E’ possibile, infatti, che siano ormai tutti presenti (basta aprire il relativo link su una pagina a parte e controllare se c’è il video embedded oppure un file torrent per scaricarlo).
Io ho tenuto un paio di talk (uno in italiano e uno nel mio maccheronico inglese) su un’idea balzana che m’era venuta in mente qualche mese e fa e che sono riuscito a completare in tempo per presentarla. Avremo modo di riprendere l’argomento fra un po’ di tempo, perché è mia intenzione scrivere una serie di articoli che esplorino il funzionamento e l’implementazione di una buona parte della virtual machine di Python (CPython).
D’altra parte compilatori, macchine virtuali, architetture degli elaboratori (CPU in particolare) sono interessi che coltivo da tempo, per cui, come potete immaginare, hanno influenzato pesantemente la scelta dei talk da seguire.
Quindi anche se i talk su Django (per chi non lo sapesse è il framework maggiormente utilizzato in Python riguardo allo sviluppo web, grazie anche alla forte “sponsorizzazione” di Google che l’ha posto alla base del suo App Engine) hanno dominato la scena (ce ne saranno stati una decina circa!), presentandolo in tutte le salse.
Diciamo che gli sviluppatori web avranno trovato pane per i loro denti, con parecchio nonché utile materiale da gustarsi, ma non essendo “di quelli” ho preferito evitare. E’ una grave mancanza, considerato che il web è divenuto parte integrante della nostra vita, ma al momento ho tutt’altro a cui pensare (però, come si suol dire, “del doman non v’è certezza”).
Le applicazioni web vanno spesso a braccetto coi database, e non sono mancati talk a riguardo, in particolare su PostgreSQL, presente ormai da anni a manifestazioni come questa, grazie anche al pregevole supporto presente per Python.
Ha fatto capolino anche qualche talk su Oracle, di cui è stato distribuito anche un DVD con un ambiente virtualizzato già pronto per potervi smanettare (cosa che conto di fare durante le ferie, spero), che purtroppo non ho potuto seguire. Grande assente, come sempre, MySQL; e a buon ragione, a mio avviso, visto che c’è di molto meglio come engine SQL (anche gratuiti / open source).
In un periodo in cui si fa gran parlare di morte (come sempre, solo annunciata) dei database relazionali, erano ovviamente presenti dei talk sui cosiddetti engine (paradigmi?) NoSQL, a cui… non ho potuto partecipare, ma avendo seguito un talk sulla completa riscrittura di Sourceforge (da PHP + MySQL sono passati a Python + MongoDB per problemi di manutenibilità e, soprattutto, scalabilità) e un altro sulla piattaforma di streaming musicale Spotify, qualcosa su di essi e il loro utilizzo l’ho sentita.
MongoDB ho già avuto modo di usarlo e quindi lo conosco (ho realizzato anche una piccola libreria a uso interno per semplificarne ulteriormente l’accesso da Python), mentre per Spotify (scritto per la maggior parte in Python, con qualcosa in Java e C/C++) hanno sfruttato Cassandra e PostgreSQL, e onestamente è l’intervento che mi ha colpito e apprezzato di più.
Il motivo è molto semplice: dopo tanto parlare di NoSQL di qua, db relazionali di là, in una netta contrapposizione ideologica e dicotomica, ci sono professionisti che presentano un prodotto vincente che li utilizza entrambi, sfruttandone i rispettivi punti di forza e, quindi, eliminando o limitandone fortemente i loro difetti, in una sinergia d’intenti che porta a una piattaforma stabile, robusta, efficiente e scalabile (e non è poco, avendo 15 milioni di brani e 10 milioni di utenti da gestire, con numeri in continua crescita).
Un altro tema fortemente dominante è stato quello delle elevate prestazioni in ambito scientifico, con diversi talk incentrati in particolare sullo sfruttamento delle moderne GPU allo scopo, scaricando sulle loro spalle l’enorme capacità di calcolo parallelo / distribuito necessaria in questi ambiti (la nostra Eleonora penso ne saprà qualcosa).
Non me ne voglia qualche collega che lavora nell’ambito delle GPU, ma sinceramente scrivere kernel per CUDA oppure OpenCL non è il massimo della semplicità e rapidità. Wrapper come PyCUDA consentono di eliminare parecchio codice “di supporto”, ma alla fine il kernel lo si deve scrivere necessariamente in C/C++ (verrà poi compilato al volo da PyCUDA, e passato alla GPU al momento dell’esecuzione).
Tutto ciò a un pythonista può non piacere, e men che meno a uno scienziato che non fa il programmatore di professione e vuole perdere pochissimo tempo per imparare un linguaggio perché, giustamente, vuol dedicarsi maggiormente alla sua professione (sarà per questo che Python è molto amato dagli astronomi, ad esempio).
Pertanto è stato veramente impressionante vedere all’opera un nuovo strumento allo scopo, CopperHead, che… permette di scrivere codice Python (per la precisione un sottoinsieme delle caratteristiche dell’intero linguaggio) che verrà automaticamente convertito in un kernel CUDA, con la possibilità di far girare lo stesso codice sulla CPU anziché sulla GPU, e il tutto in maniera assolutamente trasparente.
Tool del genere consentono di sviluppare velocemente un modello e di testarlo (grazie anche all’uso della shell interattiva di Python) il prima possibile anche su un PC senza GPU, per poi provare il codice finale su una scheda video adeguata. Anche per questo Python ha preso particolarmente piede pure in ambito economico, dove la dinamicità del mercato richiede sviluppi molto frequenti, e in poco tempo, di nuovi modelli (c’è stato qualche talk a riguardo sempre alla conferenza).
Il progetto non è ancora maturo, ma le potenzialità sono enormi, specialmente per chi, come dicevo prima, ha bisogno di concentrarsi sul suo lavoro perdendo poco tempo a imparare linguaggi di programmazione e relative problematiche. Per per rendersene conto basti guardare l’esempietto che è presente nella home page del sito del progetto:
from copperhead import * import numpy as np @cu def axpy(a, x, y): return [a * xi + yi for xi, yi in zip(x, y)] x = np.arange(100, dtype=np.float64) y = np.arange(100, dtype=np.float64) with places.gpu0: gpu = axpy(2.0, x, y) with places.here: cpu = axpy(2.0, x, y)
Una soluzione che si pone come compromesso fra PyCUDA e CopperHead è, invece, Theano, utilizzabile, al contrario del precedente, anche in produzione e che mette a disposizione alcuni tipi di dato predefiniti che possono essere manipolati con Python e convertiti poi velocemente (e in maniera trasparente allo sviluppatore) in kernel per CUDA. Il vantaggio, anche qui, è quello di non portarsi dietro tutto l’overhead richiesto da CUDA (e, in misura minore, da PyCUDA) nella scrittura del kernel.
Al solito una menzione non può che andare ai talk relativi a PyPy, progetto che in pochi anni ha permesso a Python di mostrare i muscoli anche sul piano prestazionale (impressionanti le dimostrazioni effettuate, con miglioramenti anche di un paio di ordini di grandezza!), e che ormai è abbastanza maturo da poter essere usato in produzione.
Di questo passo, e con tutte le caratteristiche introdotte finora, si propone come il candidato numero uno a prendere il posto dell’implementazione “mainstream” di Python (CPython). Se avete bisogno di velocizzare una vostra applicazione, è certamente la soluzione a cui guardare (utilissimo, in questo caso, è stato l’aver seguito il talk sulla scrittura di un emulatore Chip8 in Python), come pure se volete realizzare compilatori & macchine virtuali per altri linguaggi (è nato proprio per questo motivo, tra l’altro).
Gli ultimi due giorni sono stati dedicati ai cosiddetti sprint. Si tratta di riunioni di programmatori interessati a un particolare ambito (ad esempio CPython, PyPy, Django, SciPy, ecc.) che si tuffano in uno sviluppo “matto e disperatissimo” per implementare nuove caratteristiche (con esperti del settore; usualmente nella “tavolata” è presente qualche sviluppatore ufficiale a supporto / aiuto), oppure, ed è quello che va per la maggiore, per aiutare nei bug fix.
Ho partecipato allo sprint di CPython di sabato (domenica sono dovuto andare via, purtroppo), e devo dire che mi è stato molto utile il talk che Ezio Melotti ha tenuto sul ciclo di sviluppo di CPython e degli strumenti che si utilizzano, perché mi ha permesso di segnalare e fornire patch per un paio di semplici bug che ho individuato, facendomi quindi le ossa col sistema di ticket / issue messo in piedi dagli sviluppatori di CPython.
Tutte le belle storie hanno una fine, e purtroppo il tempo è volato via lasciando il posto ai piacevoli ricordi di quest’esperienza. Ma forse mia moglie e mia figlia hanno apprezzato di più perché, mentre partecipavo alla conferenza, erano in giro a visitare la stupenda Firenze…
Belle cose :-)
Quasi quasi mi spulcio un po’ le registrazioni di alcuni talk…
Python, il C del 2010?
Python non c’entra col C, a parte l’implementazione “mainstream” che è realizzata con quest’ultimo.
@Kod: ma lol, era un frecciata per Cesare, di la verità?
Grazie del resoconto, mi consolerò con i video dei talk, bella notizia che quest’anno siano stati più solerti nel pubblicarli.
Dopo la presenza fissa ad ogni edizione, grosso rammarico per non aver partecipato alla prima europea.
Mi rifarò senz’altro il prossimo anno anche se occorre praticamente pianificare delle ferie ad hoc (e di solito con le ferie si stacca dal lavoro…). Fa molto piacere che questa volta il materiale audio/video sia stato rilasciato in tempi da record. Forse l’importanza della manifestazione continentale ha costretto gli organizzatori a non tralasciare questo aspetto, oserei dire fondamentale.
Per far conoscere gli argomenti e creare interesse anche tra i non addetti ai lavori o tra chi non ha potuto presenziare fisicamente è importante spiegare cosa è stato fatto, chi ha parlato, di cosa si è parlato e cosa si potrà fare in futuro.
Molto bene :)
Un plauso a tutti i ragazzi della PyCon che in cinque edizioni sono riusciti a portare nomi illustri del panorama internazionale e far diventare l’Italia un punto di riferimento nel settore, a prescindere dalle tecnologie trattate.
La presenza dei video in tempi rapidissimi è stata una precisa richiesta dell’organizzazione di EuroPython. Infatti c’era un poveretto messo lì a prendere video, codificarli, e caricarli, che ha fatto anche notte in quei giorni. :|
A parte il Wi-Fi con parecchi problemi, nulla da dire sull’organizzazione dell’evento. D’altra parte 4 anni di esperienza sono serviti parecchio.
Esprimo anche il mio rammarico per non aver partecipato, soprattutto visto l’entusiasmo che hanno portato a casa titolari e colleghi.
Corro a guardarmi un po di video, grazie per la segnalazione (non sapevo che i video venissero pubblicati :D)