<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-08 22:48 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">Python3, ovviamente (ma il grosso di quello che scrivo ora come ora<br>


non è python)<br>
<br>
piuttosto, anch'io sono preoccupato, non tanto per la tecnologia, ma<br>
per le persone che vedo aprire bocca:<br>
<br>
Qualche settimana fa, alla Pycon a Firenze durante una presentazione<br>
lo speaker ha detto una cosa tipo<br>
<br>
"Anche Armin Ronacher ha avuto problemi nello scrivere un tool da<br>
linea di comando con Python3, e visto che ne sconsiglia l'utilizzo<br>
allora ovviamente ho scritto questo codice con Python2"<br>
<br>
per la cronaca, questo è il post:<br>
<a href="http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/" target="_blank">http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/</a><br>
<br>
Come potete vedere, non propaganda da nessuna parte l'idea che "è<br>
meglio usare Python2", anzi la frase finale è:<br>
<br>
"The much more likely thing to happen is that people stick to Python 2<br>
or build broken stuff on Python 3. Or they go with Go. Which uses an<br>
even simpler model than Python 2: everything is a byte string."<br>
<br>
Parla della cosa più probabile, non parla di un giudizio<br>
positivo/negativo su ciò che accadrà, ma visto che la discussione è<br>
incentrata sul supporto della comunità ad un linguaggio, è ovvio che<br>
sta esponendo un ipotetico risultato negativo (almeno per la comunità<br>
python)<br>
<br>
("everything is a byte string" fra l'altro è una semplificazione<br>
pericolosa, non illudetevi che sia la scelta ovvia & corretta: è lo<br>
stesso approccio scelto da php, foriero di bug e vulnerabilità<br>
varie.... golang ovviamente non è così naive come php)<br>
<br>
È forse Python3 perfetto? Ovviamente no. Ma il punto è (come lo stesso<br>
Armin fa notare nel suo post) il problema deriva anche dal fatto che<br>
stiamo costruendo i nostri software su delle fondamenta di<br>
pastafrolla: Unix e HTTP... nello specifico il meccanismo implicito<br>
dei locale, e l'encoding latin1/zuppa di byte di HTTP (che<br>
sinceramente non trovo così terribile, avendo scritto un server HTTP<br>
giocattolo in Python3).<br>
<br>
Se la vostra mente non è stata ancora irrimediabilmente offuscata dal<br>
koolaid dell'implicita superiorità di Unix/Linux/Macosx, per capire<br>
meglio da dove vengo vi consiglio di leggere questa vecchia perla:<br>
<br>
<a href="http://web.mit.edu/~simsong/www/ugh.pdf" target="_blank">http://web.mit.edu/~simsong/www/ugh.pdf</a><br>
<br>
Il concetto al quale volevo arrivare comunque è: Abbiamo dei tool e<br>
delle infrastrutture imperfette, dobbiamo arrangiarci con quello che<br>
abbiamo e provare a migliorarli quanto più possibile.<br>
<br>
L'approccio corretto è migliorare quelle parti di Python3 che la gente<br>
trova ostiche<br>
<br>
È una cosa fattibile, e non c'è nulla di strano, ne è un esempio<br>
.format() sui bytes:<br>
<br>
vedi: <a href="http://bugs.python.org/msg171804" target="_blank">http://bugs.python.org/msg171804</a> e la risposta di guido:<br>
<a href="http://bugs.python.org/msg180430" target="_blank">http://bugs.python.org/msg180430</a> per capire come mai "io voglio un<br>
metodo .format() sui bytes!" è come un "c'è troppo traffico! Io voglio<br>
delle strade più grandi e in maggior numero"<br>
<br>
Bisogna prestare attenzione al feedback, e capire qual'è il vero<br>
problema sottostante: così come per il traffico la vera risposta è<br>
potenziare i mezzi pubblici, disincentivare l'uso dell'auto a favore<br>
delle biciclette, etc... la vera risposta non è continuare ad usare<br>
Python2 solo per poter scrivere `b"{}".format(1)`, o fornire un metodo<br>
.format()  perfettamente equivalente, ma fornire un subset sensato di<br>
.format() che copra gli use case di Twisted e delle altre librerie che<br>
implementano protocolli simil-plain text.<br>
<br>
È ragionevole postporre la migrazione a Python3 per una vostra<br>
codebase, sopratutto se fate molto affidamento su questi dettagli?<br>
Certo che si.<br>
<br>
Ma le soluzioni sono 3:<br>
- rimarrete per sempre con una codebase legacy Python2, con<br>
vulnerabilità di sicurezza non più fixate, ma che non importeranno<br>
perchè tanto andrete a proxare/wrappare tutte le interfacce di questo<br>
software con il mondo esterno (diciamo che diventerà tipo un Cobol...<br>
e questa è una cosa che avverà comunque in un sottinsieme ristretto di<br>
casi)<br>
- vi rimboccate le maniche assieme ad altre persone disposte a creare<br>
un Python2.8, col quale poter prolungare la vita un altro po' a<br>
Python2 (che già sarà comunque longevissimo), per poi finire nelle<br>
soluzioni 1 o 3<br>
- migrate a Py3 non appena tutte le piccole asperità verranno limate via<br>
<br>
Personalmente, ho migrato (anche se i cambiamenti non sono stati<br>
mergiati) una libreria (che fa pesante uso di accesso a sequenze di<br>
byte) di ~10k righe di codice da Py2 a Py3... rendendola compatibile<br>
con entrambe le versioni<br>
<br>
Finchè le uniche persone che si lamentano di Py2 e non portano il loro<br>
codice sono le persone che fraintendono i problemi ed i benefici in<br>
questo porting e (forse proprio per questo) non sono disposti/in grado<br>
di rimboccarsi le maniche ed incominciare un lavoro su Python2.8 è<br>
ovvio che continueremo a sentirli lamentarsi (sia chiaro: Armin ed i<br>
tizi di Twisted non sono in questa categoria, in quanto loro stessi<br>
scrivono codice Py3, o lavorano seppur lentamente sul porting, o<br>
propongono/introducono migliorie in Py3)<br>
<br>
Ma questo lamento improduttivo non è altro che un rumore, che rischia<br>
di distogliere l'attenzione delle persone dal vero segnale, e che<br>
porterà i nuovi utenti a complicarsi la vita, convincendoli<br>
assurdamente che in linea di principio per loro è più conveniente<br>
iniziare con Python2, piuttosto che con Python3 (esattamente come<br>
purtroppo è successo con lo speaker di cui parlavo, che ha così<br>
interpretato il segnale distorto di Armin)<br>
<span class=""><font color="#888888"><br>
<br>
--<br>
xmpp: <a href="mailto:berdario@gmail.com">berdario@gmail.com</a><br>
bitmessage: BM-2cTYXfGiSTsnx3righ6aHcJSWe4MV17jDP<br>
gpg fingerprint: 3F8D53518012716C4EEF7DF67B498306B3BF75A0 (used just<br>
for signing commits)<br>
_______________________________________________<br>
Python mailing list<br>
<a href="mailto:Python@lists.python.it">Python@lists.python.it</a><br>
<a href="http://lists.python.it/mailman/listinfo/python" target="_blank">http://lists.python.it/mailman/listinfo/python</a><br>
</font></span></blockquote></div><br><br>Sono contento di vedere una discussione a riguardo (sono così poche...), inoltre così bene argomentata.</div><div class="gmail_extra">Riguardo la mancata adozione di Python 3 ci sono svariati motivi, ma credo che il più importante sia il fatto che ancora molte, troppe librerie "grosse" non siano state ancora portate e considerando che sono passati 5 anni da Python 3.0 direi che la cosa è abbastanza preoccupante.</div>

<div class="gmail_extra"><a href="http://py3readiness.org/">http://py3readiness.org/</a></div><div class="gmail_extra">Nomi quali Twisted, gevent, eventlet, MySQL-python, pika e molti altri implicano che centinaia di migliaia di persone sono, ad oggi, letteralmente *impossibilitate* a fare il porting e quindi non si pongono neanche il problema. ...E non solo: se anche tutte le tue dipendenze fossero soddisfatte, chi te lo dice che in futuro non potresti avere bisogno di qualcosa che non è stato ancora portato, magari basato su Twisted o che so io? Come può un'azienda fare una scelta tanto rischiosa? Semplice: non la fa. </div>

<div class="gmail_extra">Un *vero* campione statistico riguardo il successo di Python 3 IMO si potrebbe avere solamente nel momento in cui chiunque può effetturare il porting senza porsi il problema se la libreria X o Y è stata portata o meno, e calcolare le tempistiche da allora (altro che da Python 3.0).</div>

<div class="gmail_extra">Per fare un esempio concreto, il porting di Open Stack è fermo da ben una sessantina di loro dipendenze non ancora portate:</div><div class="gmail_extra"><a href="https://gist.github.com/brettcannon/9009338">https://gist.github.com/brettcannon/9009338</a><br>

</div><div class="gmail_extra">OK, la code base di Open Stack è enorme, ma il numero rimane indicativo.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">-- <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>