L’8 maggio 2008, un giorno prima dell’apertura della seconda PyCon Italia a Firenze, sono uscite in coppia Python 2.6a3 e 3.0a5, secondo il calendario fissato nella PEP 361. La conferenza (9–11 maggio) cade quindi nel mezzo del ciclo di alpha mensili che porterà alle due release finali previste per l’autunno, e nei corridoi si torna sempre sulla stessa domanda: cosa vuol dire, in concreto, portare il codice da Python 2 a Python 3.

Contesto

La PEP 361 descrive un rilascio coordinato: 2.6 e 3.0 escono insieme, il primo mercoledì di ogni mese durante la fase di test. La sequenza pubblicata finora è 2.6a1/3.0a3 il 29 febbraio, 2.6a2/3.0a4 il 2 aprile, 2.6a3/3.0a5 l’8 maggio. Le beta sono attese da giugno, la 2.6 finale a ottobre, la 3.0 finale entro fine anno.

Tenere allineate le due linee non è una scelta cosmetica. La PEP 3000 dice chiaro che la 3.0 rompe la compatibilità all’indietro: non c’è alcuna garanzia che il codice 2.x giri immutato sotto 3.0, nemmeno per un sottoinsieme del linguaggio. Le rotture si conoscono da tempo: print diventa una funzione, le stringhe passano a Unicode di default con un tipo bytes separato, la divisione tra interi cambia comportamento, dict.keys() e simili restituiscono viste al posto di liste. Il senso di 2.6 è fare da ponte: chi sviluppa su 2.6 può accendere gli avvisi di incompatibilità e usare i nomi della libreria standard riorganizzata, così prepara il codice prima del salto.

Il problema della migrazione

La domanda che torna in conferenza riguarda chi può permettersi di passare, e quando — non se Python 3 sia migliore. La risposta dipende quasi solo dalle dipendenze.

Un programma che usa la sola libreria standard si migra con 2to3, lo strumento di traduzione automatica che arriva insieme a 3.0a5 e riscrive i pattern sintattici più comuni. Ma 2to3 traduce la sintassi, non la semantica, e soprattutto non tocca le librerie di terze parti, che a maggio 2008 stanno quasi tutte ancora su Python 2. Per chi costruisce su uno stack — un ORM, un application server, un framework web — la migrazione resta bloccata finché non viene portato ogni anello della catena. Nei talk italiani il vincolo vero è proprio questo: non pesa la fatica di riscrivere il proprio codice, pesa l’attesa che si muova l’ecosistema sotto.

Lo stato dell’ecosistema web

La parte web di PyCon Italia mostra un ecosistema già assestato attorno a Python 2, cresciuto su uno standard che precede di anni la transizione a 3.0. La PEP 333, il Web Server Gateway Interface (WSGI) proposto da Phillip J. Eby nel 2003, definisce l’interfaccia tra server web e applicazioni Python e ha disaccoppiato i due lati: un’applicazione conforme a WSGI gira sotto qualunque server conforme, e i middleware si compongono a strati.

Su questa interfaccia poggiano i framework presentati nei talk. Django ha pubblicato la 0.96 e lavora verso la 1.0; Pylons monta Mako e Paste sopra WSGI; TurboGears espone un front-end WSGI. Sul versante Zope/Plone — lo stack su cui in Italia si regge una fetta non piccola dello sviluppo CMS — migrare a Python 3 è un problema di tutt’altra scala: anni di codice, ZODB, l’architettura a componenti. WSGI è il motivo per cui questo ecosistema regge bene la separazione tra server e applicazioni, ma resta un’astrazione che non rende più semplice il passaggio a 3.0: l’interfaccia è la stessa, cambia il linguaggio sotto.

Il punto critico

La gestione delle stringhe è la frattura che pesa di più sul codice web. In Python 2 str è una sequenza di byte e unicode è un tipo a parte; la conversione implicita tra i due, comoda finché tutto è ASCII, scoppia in un UnicodeDecodeError appena entra del testo non ASCII. In Python 3 il default si ribalta: str è testo Unicode e i byte hanno un tipo dedicato, senza coercizione implicita.

Per un’applicazione web questo tocca esattamente i punti caldi: corpo delle richieste HTTP, header, parametri di query, righe di database, template. Il codice 2.x che mescola str e unicode contando sulla conversione automatica non si limita a fallire la traduzione di 2to3: impone di rivedere a mano il confine tra byte e testo in ogni punto di I/O. È il lavoro che separa una migrazione meccanica da una vera, ed è il motivo concreto per cui le librerie ci metteranno tempo.

Implicazioni

Per chi lavora in Python adesso la scelta operativa è netta: sviluppare su 2.6 quando uscirà stabile, accendere gli avvisi di deprecazione, scrivere codice che giri pulito sotto -3 e rimandare il passaggio a 3.0 finché le dipendenze critiche non sono portate. La 2.6 va presa come strumento, non saltata come tappa intermedia: serve a rendere verificabile il salto successivo, dove altrimenti si procederebbe a tentoni.

Per l’ecosistema italiano qui rappresentato — molto Zope/Plone, una comunità web cresciuta su WSGI — questo vuol dire che la transizione si misurerà in anni, non in mesi, e andrà dal basso verso l’alto: prima le librerie di base, poi i framework, poi le applicazioni. Una PyCon nel mezzo di questo ciclo serve proprio a coordinare quel movimento, mettendo nella stessa sala chi mantiene le librerie e chi le usa in produzione. Tra chi sostiene questa edizione c’è anche noze, che figura tra gli sponsor della conferenza: https://www.noze.it/insights/pycon-due-italia/.

Limiti

Questi appunti sono presi nel pieno della fase alpha: 3.0a5 è una snapshot di sviluppo, le API non sono congelate e i dettagli citati qui possono cambiare prima della release finale di fine 2008. Le date stesse sono quelle pianificate nella PEP 361, e nei progetti Python gli slittamenti sono la regola più che l’eccezione. Sullo stato dei framework, la foto è quella di maggio 2008: i numeri di versione e il grado di copertura WSGI vanno verificati alla fonte prima di farci affidamento per una decisione di migrazione.

Immagine di copertina: Guido van Rossum, creatore di Python, parla seduto al Google I/O del 2008; uomo con barba e occhiali in camicia chiara — foto di Alessio Bragadini, CC BY-SA 2.0 — https://commons.wikimedia.org/wiki/File:Guido_van_Rossum_at_Google_IO_2008.jpg