<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Il giorno 13 luglio 2014 23:10, Dario Bertini <span dir="ltr"><<a href="mailto:berdario@gmail.com" target="_blank">berdario@gmail.com</a>></span> ha scritto:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">il problema più grosso è lo split fra bytes e unicode<br>
<br></blockquote><div><br></div><div>Lungi da me fare il difensore del BDFL, ma la smoother transition che state ipotizzando ed argomentando, *credo* che alla fine della fiera non possa essere fatta meglio di come sta avvenendo.<br>

 </div><div>Quello che intendo io è che ci sono troppi punti di rottura con l'avvento della 3, e non si tratta -solo- di sintassi e sottigliezze. <br></div><div>Sappiamo tutti che Python è molto cambiato, e sottovoce dico che è stato molto migliorato e che per molti aspetti, se non avesse armonizzato tutti questi aspetti, non so che futuro avrebbe avuto. IMHO, creare una versione che faccia da ponte, andrebbe a creare molti piu' svantaggi che altro, perchè in tale Python 2.8 dovrebbe convivere tutto (ed il contrario di tutto).    <br>
</div><div>Per gli aspetti per cui è possibile scrivere codice <i>python3 ready</i>, è già a disposizione il builtin __future__, per la gestione di features e keywords mandatory.  E' vero, per alcuni aspetti ci sarebbero pochi problemi. Ad esempio, con il <i>raise</i> degli errori, che con  Py2 poteva avvenire in 2 modi:<br>
</div><div><div>>>>raise TypeError, "errore xxx"<br>
</div><div>>>>raise TypeError("errore xxx")<br></div>e con py3 solo con la seconda forma: no-problem, si permettono ambedue le sintassi ed il problema è risolto.<br>Così come le eccezioni ora non possono piu' essere lanciate con<br>
<div>>>>except ValueError, my_err<br>
</div><div>ma<br></div>>>>except ValueError(my_err)<br>anche qui non sarebbe un problema permettere ambedue le sintassi.<br>Anche print vs. print() è  una modifica sintattica, gestibile in una ipotetica 2.8. <br>
</div>
<div>Anche se c'è da notare che in python 2 il seguente codice è sintatticamente valido, ma restituisce una tupla.<br></div><div>>>>print('foo','bar').<br>Ma non è sempre così agevole il discorso. Ci sono cose nella 2.7 che non sono accettabili:<br>
La gestione degli operatori di divisione degli interi in python 2 è abbastanza incomprensibile. <br></div><div>Unicode: Molto più pulito avere finalmente utf-8 *nativo*, ed a disposizione byte (e bytearray). Basta con questi str() e unicode() da wrappare assieme. </div>
<div>Sulle iterazioni, range soppianta e migliora xrange. E il __contains__, non presente nella 2, rende impossibile l'utilizzo del costrutto "x in in [x]range(foo)". <br></div><div>Alcuni comportamenti non-lineari nella gestione del namespace sono 
stati eliminati. Il namespace globale è sempre isolato dai loop for e 
comphrension varie. Niente piu' anomalie nel global namespace dopo le 
iterazioni. wow.<br></div><div>Senza entrare troppo nello specifico di iteratori/iterabili/ __next__ e __iter__, anche qui dico una sola cosa: ci basta solo il next(), niente più metodo  obj.next(). E niente piu' scelta fra input() e raw_input(). C'è solo input() che gestisce <str>. amen.<br>

Niente piu' stranezze sulla comparazione di tipi differenti<br>>>('foo','bar') > 'baz'<br></div><div>True # WTF???<br></div><div>IMHO è stata razionalizzata e potenziata anche la gestione degli iterabili. Spesso non si ha un ret val <list> ma <iterable> (zip(), map(), dict.keys(),...). Ora c'è semplicemente la possibilità di conversione in list() a seconda delle necessità di iterazione, a seconda se c'è esigenza di prestazioni/efficienza o persistenza (1-time-loop vs. n-time-loop).<br>

<br></div><div>E via discorrendo. Questi sono i primi punti che mi sono venuti in mente, sono convinto che ce ne sono molti altri. Anche se mi sto accorgendo di andare abbastanza controcorrente rispetto al pensiero diffuso in questa ML, ripeto: IMHO è difficile fare transizioni morbide, quando si deve cambiare e migliorare così tante cose. In una ipotetica 2.8 immagino codice zeppo di "if python_version()" o "try/except" per gestire un marasma del genere, ergo nello Zen andrebbero quindi cancellati:<br>
Beautiful is better than ugly.<br>Readability counts.<br>In the face of ambiguity, refuse the temptation to guess.<br>There should be one-- and preferably only one --obvious way to do it.<br>Now is better than never.<br>Although never is often better than *right* now.<br>
<br><br><br>my two cents.<br></div><div><br><br></div><div><br></div><div><br></div><div><br>
</div></div></div></div>