Perché le persone esitano a usare Python 3?

Python 3 è stato rilasciato nel dicembre 2008. Da allora è passato molto tempo, ma ancora oggi molti sviluppatori esitano a usare Python 3. Anche i framework popolari come Django non sono ancora compatibili con Python 3 ma fanno ancora affidamento su Python 2.

Certo, Python 3 ha alcune incompatibilità con Python 2 e alcune persone devono fare affidamento sulla retrocompatibilità. Ma Python 3 non è in circolazione da abbastanza tempo ora per la maggior parte dei progetti per passare o iniziare con Python 3?

Avere due versioni concorrenti presenta così tanti inconvenienti; due rami devono essere mantenuti, confusione per gli studenti e così via. Quindi perché c'è così tanta esitazione in tutta la comunità Python sul passaggio a Python 3?

Nota che non aggiorno più questa risposta. Ho un Q & A Python 3 molto più lungo sul mio sito personale all'indirizzo http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html

Risposta precedente:

(Aggiornamento dello stato, settembre 2012)

Noi (vale a dire gli sviluppatori core di Python), quando è stato rilasciato Python 3.0, avevamo previsto che ci sarebbero voluti circa 5 anni perché 3.x diventasse la scelta "predefinita" per i nuovi progetti della serie 2.x. Questa previsione è il motivo per cui il periodo di manutenzione pianificato per la versione 2.7 è così lungo.

La versione originale di Python 3.0 si è anche rivelata avere alcuni problemi critici con scarse prestazioni di I / O che la rendevano effettivamente inutilizzabile per la maggior parte degli scopi pratici, quindi ha più senso iniziare la sequenza temporale dal rilascio di Python 3.1 alla fine di giugno 2009. (Quelli I problemi di prestazioni di I / O sono anche il motivo per cui non esistono versioni di manutenzione 3.0.z: non c'è motivo per cui qualcuno vorrebbe attenersi alla 3.0 rispetto all'aggiornamento alla 3.1).

Al momento della stesura di questo documento (settembre 2012), ciò significa che al momento stiamo passando da poco più di 3 anni al processo di transizione e che la previsione sembra essere ancora sulla buona strada.

Mentre le persone che digitano il codice Python 3 vengono morse più regolarmente da cambiamenti sintattici come printdiventare una funzione, che in realtà non è una seccatura per il porting delle librerie perché lo 2to3strumento di conversione automatizzato lo gestisce abbastanza felicemente.

Il problema più grande in pratica è in realtà un semantico: Python 3 non ti consente di giocare velocemente e liberamente con le codifiche di testo come Python 2. Questo è sia il suo più grande vantaggio rispetto a Python 2, ma anche la più grande barriera al porting: devi risolvere i tuoi problemi di gestione Unicode per far funzionare correttamente una porta (mentre in 2.x, molto di quel codice ha prodotto silenziosamente dati errati con input non ASCII, dando l'impressione di funzionare, specialmente in ambienti in cui i dati non ASCII sono rari).

Anche la libreria standard in Python 3.0 e 3.1 presentava ancora problemi di gestione Unicode, rendendo difficile il porting di molte librerie (in particolare quelle relative ai servizi Web).

3.2 ha affrontato molti di questi problemi, fornendo un obiettivo molto migliore per librerie e framework come Django. 3.2 ha anche portato la prima versione funzionante di wsgiref(lo standard principale utilizzato per la comunicazione tra server Web e applicazioni Web scritti in Python) per 3.x, che era un prerequisito necessario per l'adozione nello spazio web.

Dipendenze chiave come NumPy e SciPy ora sono stati portati, utility di installazione e gestione delle dipendenze piace zc.buildout, pipe virtualenvsono disponibili per 3.x, il rilascio Piramide 1.3 supporta Python 3.2, l'imminente Django 1.5 versione include il supporto sperimentale Python 3, e il 12.0 rilascio di il framework di rete Twisted ha abbandonato il supporto di Python 2.5 per aprire la strada alla creazione di una versione compatibile con Python 3.

Oltre ai progressi nelle librerie e nei framework di compatibilità di Python 3, la popolare implementazione dell'interprete PyPy compilata da JIT sta lavorando attivamente al supporto di Python 3.

Anche gli strumenti per la gestione del processo di migrazione sono notevolmente migliorati. Oltre allo 2to3strumento fornito come parte di CPython (che ora è considerato il più adatto per le conversioni una tantum di applicazioni che non hanno bisogno di mantenere il supporto per la serie 2.x), c'è anche python-modernize, che utilizza l' 2to3infrastruttura per indirizzare il (grande) sottoinsieme comune di Python 2 e Python 3. Questo strumento crea una base di codice singola che verrà eseguita su Python 2.6+ e Python 3.2+ con l'aiuto della sixlibreria di compatibilità. La versione 3.3 di Python elimina anche una delle principali cause di "rumore" durante la migrazione delle applicazioni esistenti compatibili con Unicode: Python 3.3 supporta ancora una volta il prefisso "u" per i letterali di stringhe (in realtà non lo faqualsiasi cosa in Python 3 - è stato appena ripristinato per evitare inavvertitamente di rendere più difficile la migrazione a Python 3 per gli utenti che avevano già correttamente distinto il loro testo e i loro letterali binari in Python 2).

Quindi in realtà siamo abbastanza contenti di come stanno andando le cose: ci sono ancora quasi 2 anni per passare al nostro orizzonte temporale originale e i cambiamenti si stanno increspando bene attraverso l'intero ecosistema Python.

Poiché molti progetti non curano correttamente i metadati dell'indice dei pacchetti Python e alcuni progetti con manutentori meno attivi sono stati biforcati per aggiungere il supporto Python 3, gli scanner PyPI puramente automatizzati offrono ancora una visione eccessivamente negativa dello stato della libreria Python 3 supporto.

Un'alternativa preferita per ottenere informazioni sul livello di supporto di Python 3 su PyPI è http://py3ksupport.appspot.com/

Questo elenco è curato personalmente da Brett Cannon (uno sviluppatore di core Python di lunga data) per tenere conto di metadati di progetto errati, supporto di Python 3 che si trova negli strumenti di controllo del codice sorgente ma non ancora in una versione ufficiale e progetti che hanno fork più aggiornati o alternative che supportano Python 3. In molti casi, le librerie che non sono ancora disponibili su Python 3 mancano di dipendenze chiave e / o la mancanza del supporto di Python 3 in altri progetti riduce la domanda degli utenti (ad esempio quando il framework Django di base è disponibile su Python 3, strumenti correlati come South e django-sedano hanno maggiori probabilità di aggiungere il supporto Python 3 e la disponibilità del supporto Python 3 sia in Pyramid che in Django rende più probabile che il supporto Python 3 sarà implementato in altri strumenti come gevent).

Il sito http://getpython3.com/ include alcuni collegamenti eccellenti a libri e altre risorse per Python 3, identifica alcune librerie e framework chiave che già supportano Python 3 e fornisce anche alcune informazioni su come gli sviluppatori possono richiedere assistenza finanziaria dal PSF nel porting di progetti chiave su Python 3.

Un'altra buona risorsa è la pagina wiki della comunità sui fattori da considerare quando si sceglie una versione di Python per un nuovo progetto: http://wiki.python.org/moin/Python2orPython3

Credo che gran parte dell'esitazione provenga da due cose:

• Se non è rotto, non aggiustarlo
• La [libreria XYZ] richiesta non ha una porta 3.0

Ci sono alcune differenze nel modo in cui si comporta il linguaggio principale, delineato in questo documento . Qualcosa di semplice come cambiare "stampa" da un'istruzione in una funzione, ad esempio, romperà molto codice Python 2.x - e questo è solo il più semplice. Si sono sbarazzati delle classi di vecchio stile completamente in 3.0. Sono, in effetti, linguaggi abbastanza diversi, quindi il porting del vecchio codice non è semplice come alcuni potrebbero supporre.

Non ci sono ragioni compulsive per le aziende esistenti di dedicare tempo, denaro e sforzi alla migrazione verso qualcosa senza avere alcun cambiamento nel set di funzionalità esistente. Intendo dire che la base di codice della serie Python 2 è attiva e funzionante da molto tempo, è stabile, testata e ha tutte le funzionalità del prodotto attuali. Perché qualcuno dovrebbe spendere tempo, denaro e fatica solo per spostare Python 3 solo per motivi di migrazione su di esso.

Oltre alla post migrazione assicurando che non vi siano errori di regressione e che tutto quel mal di testa sia inevitabile.

Per i nuovi progetti la politica è chiara e semplice, tutto parte dai seguenti punti:

1. Qualche distro come Ubuntu spedisce Python 3 nella loro installazione predefinita?
2. Qual è l'ecosistema della libreria per Python 3.
3. Tutti i framework et al sono compatibili con Python 3. ecc. Ecc.

È il tuo solito processo di "scelta di una nuova lingua". È qui che entra in gioco il problema dell'uovo di gallina, non molte persone lo usano perché non molte persone lo usano. Alla fine nessuno ha voglia di trasferirsi.

La rottura della retrocompatibilità non è mai stata una buona cosa, alla fine si finisce sempre una buona percentuale di utenti.

Intorno al momento del rilascio di Python 2.0, Python stava rapidamente crescendo in popolarità. C'erano molti nuovi utenti che utilizzavano naturalmente l'ultima versione, poiché non dipendevano dalle versioni precedenti. Con un sacco di gente che adotta 2.0 di default, c'è stata molta pressione sugli sviluppatori di biblioteche ecc.

Al momento del rilascio di Python 3.0, esisteva già un numero enorme di utenti dipendenti da Python 2.0 e ovviamente la crescita esponenziale (mantenendo un fattore costante rispetto agli utenti esistenti) non poteva essere sostenuta indefinitamente.

Personalmente, le nuove funzionalità di Python 2 sembrano molto più avvincenti di quelle fornite da Python 3.

Pensavo che Python 3 alla fine avrebbe preso il controllo comunque, ma non ne sono così sicuro ora. Ma non è solo Python che ha questo problema. Dopo tutto, quante persone usano onestamente Perl 6? È stato un po 'più lungo di Python 3, IIRC.

Un grande ostacolo per me, che non credo possa essere affrontato dalla traduzione automatica, è la divisione intera. Ho dei codici scientifici che si basano su x / 2 che dà x arrotondato per difetto (quando x è intero).

Python 3 non lo farebbe, ma darebbe una risposta .5 (per x dispari).
Non posso semplicemente sostituire tutto / nel mio codice con // perché a volte faccio la divisione float e quindi voglio il comportamento float.

Quindi, per eseguire il porting su Python 3, dovrò cercare tra decine di migliaia di righe di codice, controllando ogni / e vedendo se riesco a capire se dovrebbe essere / o //.

Python 3 è bello avviare un nuovo progetto se tutte le librerie di cui hai bisogno sono già portate su Py3k.

Se questo non è un'opzione, usando Python 2.7 è il meglio dei due mondi: avete la maggior parte ogni libreria creata per Python 2.x e si può gradualmente modificare il codice per essere Py3k-compatibili, in modo che la migrazione è facile quando si decide su esso. L'elenco delle chicche di sintassi di Py3k che hai già in 2.7 è piuttosto lungo, ma non dimenticare di importare da __future__. I miei preferiti sono Unicode per impostazione predefinita e la divisione produce sempre un float.

Dal punto di vista dei servizi Web: nessuno dei principali framework server né framework Web supporta Python3.

Aggiornamento: Ovviamente è stato il caso all'inizio del 2011, a partire da ora (fine 2013), la maggior parte dei framework principali funziona con Python3. Tuttavia alcuni non sono ancora compatibili. Un esempio significativo sarebbe Twisted, dove è ancora in corso di elaborazione .

Non ci sono ragioni convincenti che ho visto usare P3K a meno che tu non stia facendo un pesante lavoro con i18n. Nelle mie incursioni, ho trovato il pervasivo Unicode come una barriera al mio lavoro (ASCII) e i generatori obbligatori per intasare il mio codice.

Tra qualche anno 3 presenterà un ambiente più avvincente, ma non oggi.

Le distribuzioni non rendono disponibile Python3. Ci sono alcune distinzioni marginali che già passano da Python2. Ma le varianti Linux tradizionali come Debian, Ubuntu ecc. Questo è il motivo principale per me come autore dell'applicazione non farlo neanche.

Anche se ho preparato la transizione e ho anche cercato di evitare i costrutti di sintassi che sono stati incompatibili , non posso testarlo correttamente. Si riduce davvero al problema del pollo e delle uova.