<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-13 23:10 GMT+02:00 Dario Bertini <span dir="ltr"><<a href="mailto:berdario@gmail.com" target="_blank">berdario@gmail.com</a>></span>:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">2014-07-13 11:05 GMT-07:00 Giovanni Porcari <<a href="mailto:giovanni.porcari@softwell.it">giovanni.porcari@softwell.it</a>>:<br>


<div class="">><br>
> Domanda da ignorante: Ma è radicalmente impossibile pensare ad una versione<br>
> di python 3 che sia in qualche modo completamente retrocompatibile  con la 2.7<br>
> o con una ipotetica 2.8 ?<br>
<br>
</div>il problema più grosso è lo split fra bytes e unicode<br></blockquote></div><div class="gmail_extra"><br></div>A conti fatti direi che è l'unico, il solo aspetto che rende Python 3 profondamente diverso dal 2. Tutto il resto è facilmente portabile con 2to3 e six con relativamente poco sforzo, specialmente se il target è Python 2.6+. La distinzione netta tra bytes e "testo" è stata una scelta molto (troppo?) coraggiosa e moderna, "giusta" in linea di principio ma fortemente non retrocompatibile e a cui si deve l'attuale spaccatura.</div>

<div class="gmail_extra">Non è un caso che proprio i progetti fortemente basati sull'I/O come MySQL-python, Twisted e gevent sono quelli che ancora latitano perchè (esperienza personale fatta con pyftpdlib) far coesistere due tipi che prima erano intercambiabili e di colpo non lo sono più, specialmente in quel tipo di applicazioni, è veramente un casino.</div>

<div class="gmail_extra">Hai bytes che ti viaggiano "sul cavo" come bytes in entrata e in uscita ma che a livello di codice devi trattare com testo, per cui ti devi porre 2 problemi che prima non ti ponevi: sapere in anticipo in che encoding trattarli e cosa fare se quello che ti entra non è convertibile "non per colpa tua". </div>

<div class="gmail_extra">Problemi che in linea di principio è giustissimo porsi se si vivesse in un mondo perfetto dove client, file system e sistemi operativi usassero tutti correttamente UTF-8, ma che non corrisponde a quello reale in cui molte volte non sai l'encoding e vuoi semplicemente che una cosa *funzioni* il 99% delle volte e rispondere "cazzi tuoi" a quell'1% di utenza che usa un client fatto male. E guarda caso questo è esattamente il trend adottato dalla maggior parte delle aziende, che sono quelle che determinano il successo di un prodotto.</div>

<div class="gmail_extra">Se non ci fosse stata la modifica a bytes/unicode *oggi* saremmo già tutti su python 3, ne sono assolutamente convinto, sia perchè il 2 è destinato a morire e sia perchè il 3 è dannatamente buono (nuova gestione delle eccezioni, traceback concatenati, tuple unpacking, mandatory kwargs, __pycache__, TypeError ogni volta che mischi/compari mele e pere, pathlib, asyncio, enum... tutta roba buona).<br>

</div><div class="gmail_extra">3 / 2 = 1.5, "except Exception as ex:", list(range), metaclass=..., etc. sono problemi solo un po' più difficili di quelli che si affrenterebbero in transazioni come dalla 2.4 alla 2.5 per dire, e che risolvi egregiamente con six. Un Python 2.8 non risolverebbe assolutamente nulla se non prolungare ulteriormente l'attesa, perchè apparentemente non è possibile trovare un punto di incontro tra come Python 2 e 3 gestiscono "testo" e bytes. O li si gestisce in un modo o in un altro, ed il problema stà unicamente lì.</div>

<div class="gmail_extra"><div><br></div>-- <br><div dir="ltr"><div>Giampaolo - <a href="http://grodola.blogspot.com" target="_blank">http://grodola.blogspot.com</a></div><div><br></div></div>
</div></div>