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