<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-07-13 5:01 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-12 11:28 GMT-07:00 Giampaolo Rodola' <<a href="mailto:g.rodola@gmail.com" target="_blank">g.rodola@gmail.com</a>>:<br>
<div>> Sono contento di vedere una discussione a riguardo (sono così poche...),<br>
> inoltre così bene argomentata.<br>
> Riguardo la mancata adozione di Python 3 ci sono svariati motivi, ma credo<br>
> che il più importante sia il fatto che ancora molte, troppe librerie<br>
> "grosse" non siano state ancora portate e considerando che sono passati 5<br>
> anni da Python 3.0 direi che la cosa è abbastanza preoccupante.<br>
> <a href="http://py3readiness.org/" target="_blank">http://py3readiness.org/</a><br>
> Nomi quali Twisted, gevent, eventlet, MySQL-python, pika e molti altri<br>
> implicano che centinaia di migliaia di persone sono, ad oggi, letteralmente<br>
> *impossibilitate* a fare il porting e quindi non si pongono neanche il<br>
> problema. ...E non solo: se anche tutte le tue dipendenze fossero<br>
> soddisfatte, chi te lo dice che in futuro non potresti avere bisogno di<br>
> qualcosa che non è stato ancora portato, magari basato su Twisted o che so<br>
> io? Come può un'azienda fare una scelta tanto rischiosa? Semplice: non la<br>
> fa.<br>
<br>
</div>Vero, ma non tutte le aziende sono uguali.<br>
<br>
Diverse aziende/persone sono invece portate a scommettere su una<br>
tecnologia, e non si preoccupano troppo del fatto che in futuro<br>
"potrebbero avere bisogno di qualcosa che non esiste per il loro<br>
stack/linguaggio"... c'è gente che sceglie OCaml, oppure si scrive il<br>
proprio linguaggio, o la propria implementazione di un linguaggio<br>
<br>
vedi anche la stessa Dropbox con Pyston: mi pare che le estensioni C<br>
non le supportino ancora, e fino ad allora non sarà certo un drop-in<br>
replacement per CPython<br>
<br>
In confronto allo sforzo di crearsi e mantenere il proprio linguaggio,<br>
l'effort richiesto per portare una sola libreria, che possa<br>
ipoteticamente servire in futuro, sfuma... queste aziende, se hanno<br>
bisogno hanno il know-how per scrivere da 0 quello che gli serve<br>
<br>
(non ho nulla contro aziende più conservative: alla fine si tratta<br>
sempre di fare la solita scelta make-or-buy)<br>
<div><br>
> Un *vero* campione statistico riguardo il successo di Python 3 IMO si<br>
> potrebbe avere solamente nel momento in cui chiunque può effetturare il<br>
> porting senza porsi il problema se la libreria X o Y è stata portata o meno,<br>
> e calcolare le tempistiche da allora (altro che da Python 3.0).<br>
> Per fare un esempio concreto, il porting di Open Stack è fermo da ben una<br>
> sessantina di loro dipendenze non ancora portate:<br>
> <a href="https://gist.github.com/brettcannon/9009338" target="_blank">https://gist.github.com/brettcannon/9009338</a><br>
> OK, la code base di Open Stack è enorme, ma il numero rimane indicativo.<br>
><br>
<br>
</div>Concordo in toto, ma la situazione non è così brutta come può sembrare:<br>
<br>
Contando le dipendenze in quel gist, 65 è un numero molto inferiore<br>
alle quasi 200 dipendenze complessive<br>
<br>
E guardando i primi progetti in quella lista, parti di essi funzionano<br>
già con Python3 (boto) o c'è un rewrite che supporta Python3<br>
apparentemente (cmd2)</blockquote><div><br></div><div><br></div><div>65 su 200 è circa il 25%: non è affatto poco. Inoltre considera che alcune di quelle saranno portate tra tanto (gevent / eventlet), altre probabilmente non saranno portate affatto e a farmelo pensare è il fatto che non l'abbiano fatto finora. In quel caso il processo si allunga ulteriormente perchè hai 3 possibilità: portarle tu, aspettare un fork o eliminarle in toto (se puoi). Applica questa formula ad un progetto grosso come OpenStack e ti renderai conto che a conti fatti ad oggi il porting non è proprio possibile. Ridimensiona il problema a una code base più contenuta ed avrai comunque più o meno lo stesso risultato. Realisticamente stiamo guardando ad un processo che potrebbe benissimo durare altri 5 anni o più, durante il quale la 2.7 diventerà sempre più obsoleta fino a non essere più comptetitiva come prodotto (nel 2020 cesseranno di mantenerla). Già dal punto di vista della sicurezza sono spuntate le prime magagne con SSL e tutti i moduli che ne dipendono e la compilazione di estensioni C su Windows è già ad oggi un problema in quanto Microsoft non distribuisce più Visual Studio 2008. A parer mio la situazione è preoccupante non tanto per il numero esiguo di migrazioni fatte finora, quanto per il fatto che non vedo segnali di miglioramento per l'immediato futuro. Le migliorie sintattiche/puristiche interessano poco e la migliore gestione di unicode per molti è addirittura un problema anzichè un vantaggio. Di fatto credo che ad oggi l'unico vero incipit a migrare sia il fatto che la 2.7 diventerà obsoleta quindi si sarà semplicemente obbligati a migrare (e neanche tutti) ma quando l'incipit è un bastone anzichè una carota non è mai un bene.</div>

<div><br></div></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>