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!
Ormai è un bel po’ che scrivo in Python, lo ritengo davvero ottimo quanto semplice, e questi cambiamenti erano attesi come lo saranno quelli del PHP per -guarda caso- le stesse istruzioni “fuori standard” (ad esempio print).
Bello lo Zen di Python. Trovo che siano delle regole molto valide anche in generale su qualunque aspetto della programmazione.
Riguardo Python, mi piacerebbe che in una delle future evoluzioni della piattaforma sia possibile generare in modo semplice degli eseguibili compilati staticamente e stand alone, o al limite dei paccehtti compilati in bytecode con tutte le librerie necessarie incluse tranne quelle standard e l’interprete (tipo i Jar di Java).
So che c’è Py2Exe ma l’ulima volta che l’ho usato mi è parso complicato, ha generato un eseguibile enorme e comunque è un progetto separato, sarebbe bello se questa funzionalita venisse portata avanti in modo ufficiale direttamente da Guido.
Veramente contento, aspettavo questo update da tempo seguendo i vari changelog :)
Pietro, per creare eseguibili dai un’occhiata anche a pynstaller ;)
per “Cla”
l’ultimo Pyinstaller è stato rilasciato il 20 dicembre 2006, la release in sviluppo non ha risolto il problemi con la ver. 2.6 di python e adesso siamo alla rivoluzionaria 3.0 che si fa?
L’idea di fondo quando succedono queste cose è che sono sempre progetti per smanettoni o entusiasti, pertanto inaffidabili per chi ci deve investire risorse.
Mi sembra di ricordare anche ironpyton, pytoexe e chissà quanti altri a dimostrazione della loro inaffidabilità.
Purtroppo non c’è una grossa comunità dietro che li sviluppa, come giustamente fai notare.
L’unico di cui sento parlar bene è Py2Exe, che è abbastanza aggiornato. Il fatto che generi file di grosse dimensioni molto probabilmente è dovuto alle librerie che include. Ad esempio se si usa roba come WxPython, sicuramente il pacchetto molto grande.
IronPython non è un progetto inaffidabile: da tempo chi lo sviluppava è finito a lavorare per conto di Microsoft ed è, infatti, abbastanza maturo (se consideri tutto il lavoro che ci sta dietro). Tant’è che fa parte dei 4 linguaggi che è possibile usare per sviluppare applicazioni web con SilverLight (ci sono un bel po’ di tutorial in giro a cui ti consiglio di dare un’occhiata).
Quanto alla questione dei problemi relativi alle versioni 2.6 e 3.0 ne parlerò in un prossimo articolo, visto che lavorando tutti i giorni con Python ho problemi ad aggiornare le mie applicazioni, e penso che la questione meriti un approfondimento.
@Pietro R.: Guido non ci lavorerà mai perché è già molto impegnato con Google e con lo sviluppo del linguaggio stesso (Google gli permette di lavorare al linguaggio per il 50% del suo impiego).
@FabioFLX: francamente mi sembra molto strano, perché gli sviluppatori di PHP tengono particolarmente alla retrocompatibilità. Se è come dici, farà sicuramente piacere veder mettere un po’ d’ordine anche a questo linguaggio. :)
IronPython con le evoluzioni recenti di DotNET e l’aggiunta del DLR all’infrastruttura Microsoft è uno dei progetti derivati senz’altro più interessanti (forse il più interessante). La possibilità di utilizzare compiutamente gli oggetti generati in ambito NET uniti alle librerie native di Python è un plus che va seguito soprattutto per chi è abituato a sviluppare con linguaggi dinamici, è interessato a NET ma non vuole saperne di C#.
[…] appena vengono annunciate nuove versioni di un programma che utilizza, un buon programmatore comincia a farsi consumare la mente da un tarlo: quello della […]