Python 3.9 è qui, e io sto invecchiando :-)

E così eccoci arrivati a Python 3.9, ufficialmente già la seconda release ad avere un numero più grande di quanto Python 2 non sia mai arrivato nei suoi 20 anni di vita. Il mondo corre sempre più in fretta e a me sembra di invecchiare allo stesso ritmo. 

Tra la versione 2.4 (novembre 2004) e la 2.5 (settembre 2006) passarono quasi due anni. Per la 2.6 (ottobre 2008), altrettanti. La 2.7 arrivò solo a luglio 2010. Oggi, la versione 3.9 inaugura una cadenza annuale delle release, nientemeno: d'ora in avanti, a ogni ottobre dovremo aspettarci una nuova versione. 

L'altra faccia della medaglia di questa accelerazione, naturalmente, è che le novità per ciascuna release sono di meno: la versione 2.5, per dire, introduceva in un botto solo le espressioni condizionali, gli import relativi, i context manager, le coroutine (l'inizio di una lunga strada che avrebbe portato ad asyncio e al supporto per l'esecuzione asincrona)... e un bel po' di feature "minori" (cose tipo any e all...  robette, insomma!).  Ricordo che all'epoca ogni nuova release richiedeva parecchie settimane per essere "digerita"; per molti aspetti, sembrava un Python diverso ogni volta. Tutto questo, in un linguaggio che era pur sempre considerato molto conservativo sulle novità da adottare (vi ricordate tutta la cautela di "from __future__ import"?). 

 

Oggi, al confronto, le nuove release sembrano dei bugfix e i bugfix quasi non si notano più. Non che mi lamenti... O forse sì. Forse è una mia impressione, ma una volta c'erano delle cesure più nette: ti beccavi un sacco di roba nuova in un colpo solo, ma poi avevi due anni di tempo in cui non succedeva più niente. Adesso tutto evolve probabilmente alla stessa velocità, ma aggiungendo un pezzetto alla volta. Il risultato è che diventa più difficile scrivere codice che mira a una versione specifica del linguaggio. A mitigare il problema, per fortuna, adesso c'è una policy più stringente sulle versioni supportate: la 3.5 esce di scena adesso, e la 3.6 non sarà più supportata dall'anno prossimo. In pratica, un progetto che inizia oggi può tranquillamente mirare solo più alla "forchetta" 3.7-3.9, che sono versioni relativamente omogenee e moderne. Ricordo che, ai tempi della 2.7, occorreva comunque cercare di scrivere codice compatibile all'indietro fino alla 2.4... cosa che francamente diventava impossibile. 

In ogni caso, una cadenza di release più ravvicinata produrrà inevitabilmente una maggiore dispersione delle installazioni: una volta, versioni come la 2.4 erano il "golden standard" che trovavi dovunque, per molti anni; oggi è probabile che molta gente aggiorni in modo discontinuo, e su ogni macchina puoi trovare una versione diversa. Per esempio, non mi è chiaro (o forse, piuttosto, non è chiaro) come le varie distribuzioni Linux intendono adeguarsi al nuovo ritmo di release che ci sarà d'ora in poi. 


Che cosa c'è di interessante nella 3.9.

Detto questo, su che cosa vale la pena di soffermarsi, quindi, in questa versione 3.9 di Python? 

Prima di tutto, le notizie che contano per noi utenti Windows. A partire dalla 3.9, Windows 7 non è più supportato: non cercate di installarlo sul vostro vecchio pc... non funziona! Inoltre, nonostante sia ancora disponibile l'installer a 32 bit, finalmente l'installer di default proposto sarà quello a 64 bit (e direi che era anche ora). 

Per il resto, la novità più evidente è probabilmente il nuovo operatore che fa il lavoro di dict.update per unire due dizionari. Tuttavia la cosa più importante dietro le quinte è sicuramente il nuovo PEG parser per la sintassi del linguaggio: l'ultimo lavoro di Guido è sicuramente una novità fondamentale che determinerà l'evoluzione di Python per gli anni a venire, anche si tratta di una questione molto tecnica di cui gli utenti normali non si accorgeranno neppure. 

Ma l'aspetto che personalmente mi sta più a cuore è l'introduzione del supporto al database IANA delle timezone, che finalmente rende il modulo datetime... utilizzabile in pratica (e dopo 17 anni di vita, direi che forse era anche il caso). 

La storia di "datetime" è lunga e complessa. Il modulo è stato introdotto in Python 2.3, con una architettura volutamente molto astratta e "naive". In pratica propone una classe per rappresentare i momenti temporali (datetime.datetime) che però è... solo una scatola vuota, che mette a disposizione alcune operazioni astratte, e lascia alle implementazioni concrete il compito di rappresentare le date nel mondo reale. Questa limitazione, unita a un API piuttosto farraginosa, ne ha fatto uno dei moduli meno amati della libreria standard: nel tempo sono nate diverse librerie esterne per rappresentare meglio le date nel mondo reale. Fino a qualche tempo fa l'opzione migliore sembrava Pytz, che purtroppo però aveva notevoli difetti nel calcolo delle timezone. Oggi la cosa migliore è usare invece Dateutil, che fa le cose per bene. 

Nel frattempo anche datetime nella libreria standard ha subito un lentissimo processo di evoluzione. In Python 3.2 è stata introdotta la classe datetime.timezone (ancora pur sempre un guscio vuoto) per rappresentare una timezone; in Python 3.6 finalmente datetime.datetime ha guadagnato il supporto per l'ora "doppia" che accade in autunno quando si torna all'ora solare. E in tempi recenti Paul Ganssle, che mantiene Dateutil ed è diventato il guru-di-fatto di questi argomenti nella comunità Python, ha spinto moltissimo per l'introduzione definitiva del database IANA delle timezone (detto anche Olsen database) dentro la libreria standard. Questo significa che finalmente anche datetime.datetime, senza ricorrere a librerie esterne, avrà gli strumenti per sapere che il 29 marzo 2020 ore 2:30, da noi in Italia, non c'è mai stato, e cose così: ovvero, per rappresentare correttamente il concetto di "istante temporale" nel mondo reale. 

Sono argomenti che mi hanno sempre affascinato molto, e su cui prima o poi mi piacerebbe scrivere un tutorial. Ma per il momento, il succo è che da questa versione 3.9, datetime può essere usata non solo come infrastruttura astratta per librerie concrete, ma già come strumento di calcolo delle date nel mondo reale. Ovviamente questo non vuol dire che Dateutil, Arrow e un sacco di altre librerie esterne andranno in pensione: possono offrire pur sempre un'API più piacevole da usare, e si concentrano su determinati aspetti dell'implementazione. Ma d'ora in poi dovrebbe essere possibile, almeno in linea di principio, farsi un'applicazione di calendaring completa e corretta senza abbandonare la libreria standard.


Commenti

  1. C'è una frase che mi piace: “La gente non smette di giocare perché diventa vecchia; diventa vecchia perché smette di giocare”... mi sembra che tu non abbia ancora smesso di divertirti e quindi non invecchierai facilmente :)
    Interessante queste riflessioni su datetime, il tempo è una cosa che sinceramente ho sempre evitato di dover maneggiare ma - quando ho dovuto farlo - mi ha sempre tenuto sulle spine... a partire da Access e dai suoi famigerati campi data/ora (sob).
    Complimenti per gli ottimi libri e gli aggiornamenti, leggendo ho imparato ancora qualcosa che non conoscevo, qualche trucco comodissimo (ho scoperto il Windows Terminal... non riesco più a vivere senza).
    By the way ti riferisco che ci sono un paio di refusi in Python in Windows, capitolo 10.2 "Office" (e anche nei link utili, alla fine del capitolo 10.4), dove il correttore ortografico ha cambiato tutti gli "odbc" in "odcb" (ho utilizzato con somma soddisfazione questa tecnica per maneggiare una mia base dati mdb e funziona alla perfezione).
    Hai fatto un lavoro notevole e molto apprezzato. Basta complimenti o davvero, non rilascerai più gli aggiornamenti :)

    RispondiElimina
    Risposte
    1. Grazie della segnalazione! Così a occhio, penso che di quel libro farò un aggiornamento ogni sei mesi, giusto per verificare se nel frattempo non è cambiato qualcosa... La triste verità è che ha pochissimi lettori, quindi non sono molto invogliato... il libro su wxPython va molto meglio, e quindi, per rispetto ai lettori, dovrei buttarmi di più su quello... Poi ho qualche progettino nuovo che mi gira per la testa... vedremo...
      Per quanto riguarda le date, su questa cosa (e su unicode) sono un po' un geek... mi affascina davvero tanto... anche qui, magari un giorno scappa un libricino...

      Elimina

Posta un commento

Post più popolari