Ci siamo: dopo ben tre anni di lavorazione, mercoledì scorso è stata finalmente rilasciata la versione 3.0 di Python. Un sforzo immane, che ha richiesto parecchio tempo a causa dei numerosi cambiamenti che sono stati apportati al linguaggio e alle librerie standard in dotazione (di cui è notoriamente ben fornito).
In realtà chi segue la mailing-list degli sviluppatori sa che nelle intenzioni Python 3.0 avrebbe dovuto esser rilasciato contemporaneamente alla versione 2.6 (che è arrivata lo scorso 1 ottobre), ma a causa di alcuni bug non banali ancora presenti la comunità degli sviluppatori ha preferito allungare la tabella di marcia per arrivare con un prodotto stabile e ben testato.
Già. Python 2.6 e Python 3.0: quali le ragioni di questo duplice rilascio? E’ presto detto. Python 2.6 rappresenta un elemento di continuità col passato. Infatti nonostante il linguaggio e la libreria standard presentino delle innovazioni, rimangono entrambi quasi del tutto retrocompatibili con le precedenti versioni (fatta eccezione per l’introduzione di nuove keyword; ma questo capita praticamente con tutti i linguaggi di programmazione che introducono nuove funzionalità che ne abbisognano). Il vecchio codice funzionerà senza o, al limite, con delle piccolissime modifiche; quindi assolutamente nulla di “traumatico”.
Python 3.0, invece, non s’è posto il problema della retrocompatibilità a tutti i costi. Questa versione del linguaggio nasce alla luce di una ben precisa esigenza: dare una “ripulita” al linguaggio rendendolo più coerente con la filosofia con cui è nato e si è evoluto. Detto in questo modo sembra che Python sia diventato di colpo un letamaio; ovviamente non è così. Anche in versione 2.6 Python rimane un bel linguaggio, con una sintassi molto semplice e chiara (tanto che è stato coniato per lui il termine di pseudocodice eseguibile).
Cosa vuol dire quindi “ripulire” il linguaggio? In gergo significa renderlo più pythonic; più vicino a quello che viene definito come lo Zen di Python. Ed è proprio in quest’ottica che possiamo inquadrare i cambiamenti apportati.
Prendiamo il caso dell’istruzione print, che serviva per stampare a video (o su file). Fino alla 2.6 era, appunto, un’istruzione ed era più semplice da usare rispetto alla versione 3.0, quindi rientrava nel caso Simple is better than complex, ma essendo un’istruzione anche in quello Special cases aren’t special enough to break the rules; inoltre sempre in questo caso rientravano la redirezione dell’output su file, la possibilità di non andare a capo alla fine della riga, e l’obbligo di usare sempre e soltanto lo spazio come separatore degli elementi da visualizzare.
In Python 3.0 print è diventata una funzione built-in, quindi al pari di tutte le altre già presenti. E’ più scomoda da usare (adesso è necessario aggiungere una parentesi aperta all’inizio e alla fine degli elementi da stampare), ma in compenso la redirezione su file è diventata un parametro come un altro, e lo stesso vale per il separatore degli argomenti (che, tra l’altro, adesso è anche possibile cambiare) e la possibilità di specificare se andare a capo o meno. Insomma, tutto è diventato standard, esattamente come avviene per tutte le altre funzioni.
Altro macroscopico cambiamento è rappresentato dalla presenza di un solo tipo stringa. In precedenza Python permetteva di utilizzare come stringhe una qualunque sequenza di byte (che era il tipo stringa standard o predefinito) oppure una sequenza di caratteri unicode (il tipo stringa unicode, appunto). Entrambi i tipi erano miscelabili a piacere, nel senso che, ad esempio, concatenare una stringa “standard” con una unicode comportava automaticamente la conversione della prima al secondo tipo, e la successiva operazione di concatenazione.
Adesso è presente soltanto la seconda versione, quindi le uniche stringhe a disposizione sono quelle unicode. Questo per rispettare il principio del There should be one– and preferably only one –obvious way to do it. Il vecchio tipo stringa non è scomparso, ed è diventato un nuovo tipo chiamato bytes, ma non è più possibile miscelare stringhe (unicode) con (stringhe) bytes: si rende necessario un’esplicita (Explicit is better than implicit) conversione al primo o al secondo tipo.
Sempre fedele al principio There should be one– and preferably only one –obvious way to do it, notiamo che non esistono più interi (a 32 bit a 64 bit fissi, a seconda dell’architettura) e interi “lunghi” (virtualmente illimitati, a prescindere dall’architettura): c’è soltanto quest’ultimo tipo, che è diventato il “nuovo” (ed unico) tipo intero.
Questi sono i cambiamenti più evidenti, ma ovviamente ne esistono diversi altri (anche alle librerie standard) che è possibile leggere in questo link.
Indubbiamente la parziale assenza di retrocompatibilità è un grosso peso che Python 3.0 si porta dietro, ma personalmente ammiro il coraggio di una comunità che preferisce rimanere fedele alla filosofia che ha sempre contraddistinto questo linguaggio, piuttosto che farlo evolvere aggiungendo via via i “pezzi” mancanti (per mettersi al passo con le innovazioni presenti in altri linguaggi) perdendo di vista quella che è la sua carta d’identità e che lo “caratterizza”.
Il pitone, insomma, cambia pelle, ma… rimane pur sempre un pitone!
