Come pensi di gestire la migrazione a Python 3?

https://stackoverflow.com/questions/172306

05-07-2019
|

Domanda

Sono sicuro che questo è un argomento che è nella mente della maggior parte degli sviluppatori di Python considerando che Python 3 uscirà presto. Alcune domande per farci andare nella giusta direzione:

Avrai una versione di Python 2 e Python 3 da gestire contemporaneamente o avrai semplicemente una versione di Python 3 una volta terminata?
- Hai già iniziato o pensi di iniziare presto? O pensi di aspettare fino a quando uscirà la versione finale per entrare in pieno svolgimento?

Soluzione

Ecco il piano generale per Twisted. Inizialmente stavo per blog questo, ma poi ho pensato: perché blog quando ho potuto ottenere punti per questo?

Aspetta che qualcuno se ne occupi.

In questo momento, nessuno ha Python 3. Non faremo un sacco di sforzi fino a quando almeno un utente reale non è uscito e ha detto " Ho bisogno del supporto di Python 3.0 " e ha una buona ragione per questo a parte dal fatto che 3.0 sembra brillante.
Attendi fino alla migrazione delle nostre dipendenze.

Un grande sistema come Twisted ha una serie di dipendenze. Per cominciare, il nostro include:
- Zope Interface
- PyCrypto
- PyOpenSSL
- pywin32
- PyGTK (sebbene questa dipendenza sia purtroppo molto leggera in questo momento, spero che al momento della migrazione, Twisted avrà più strumenti GUI)
- pyasn1
- PyPAM
- gmpy
Alcuni di questi progetti hanno una propria gamma di dipendenze, quindi dovremo aspettare anche quelli.
Aspetta che qualcuno si preoccupi abbastanza per aiutare .

Ci sono, caritatevolmente, 5 persone che lavorano su Twisted - e io dico "caritatevolmente" perché mi conta, e non mi impegno da mesi. Abbiamo oltre 1000 biglietti aperti in questo momento, e sarebbe bello sistemare effettivamente alcuni di questi & # 8212; correggi i bug, aggiungi funzionalità e in genere rendi Twisted un prodotto migliore a sé stante & # 8212; prima di passare il tempo a portarlo su una versione sostanzialmente nuova della lingua.

Questo include potenzialmente sponsor abbastanza premurosi da pagare per noi per farlo, ma spero che ci sarà un afflusso di volontari che si preoccupano del supporto 3.0 e vogliono aiutare a far avanzare la comunità.
Segui i consigli di Guido.

Questo significa non cambieremo le nostre API in modo incompatibile e seguiremo lo sviluppo di transizione linee guida pubblicate da Guido l'anno scorso. Questo inizia con avere unit test ed eseguire lo strumento di conversione 2to3 sulla base di codice Twisted.
Segnala bug e file patch per lo strumento 2to3 .

Quando arriveremo al punto in cui lo stiamo effettivamente usando, prevedo che ci saranno molti problemi con l'esecuzione di 2to3 in futuro. L'esecuzione su Twisted in questo momento richiede un tempo estremamente lungo e (l'ultima volta che ho controllato, che era un po 'di tempo fa) non è possibile analizzare alcuni dei file nel repository Twisted, quindi l'output risultante non verrà importato. Penso che dovranno esserci un discreto numero di storie di successo da piccoli progetti e un sacco di martellate sullo strumento prima che funzioni davvero per noi.

Tuttavia, il team di sviluppo di Python è stato molto utile nel rispondere alle nostre segnalazioni di bug e le prime risposte a questi problemi sono state incoraggianti, quindi mi aspetto che tutti questi problemi vengano risolti in tempo.
Mantiene la compatibilità 2.x per diversi anni.

Al momento, Twisted supporta python da 2.3 a 2.5. Attualmente, stiamo lavorando al supporto 2.6 (che ovviamente dovremo finire prima della 3.0!). Il nostro piano è di rivedere le nostre versioni supportate di Python in base alle versioni supportate a lungo termine di Ubuntu - la versione 8.04, che include Python 2.5, sarà supportata fino al 2013. Secondo i consigli di Guido avremo bisogno di abbandonare il supporto per 2.5 per supportare 3.0, ma spero di poter trovare un modo per aggirare il problema (siamo piuttosto creativi con hack compatibili con la versione).

Quindi, stiamo pianificando di supportare Python 2.5 almeno fino al 2013. Tra due anni Ubuntu rilascerà un'altra versione supportata a lungo termine di Ubuntu: se esistono ancora e restano nei tempi previsti, sarà 10.04. Personalmente sto indovinando che questo verrà fornito con Python 2.x, forse python 2.8, come / usr / bin / python , perché c'è un'enorme quantità di software Python impacchettato con la distribuzione e richiederà molto tempo per aggiornare tutto. Quindi, a cinque anni da poi , nel 2015, possiamo iniziare a cercare di eliminare il supporto 2.x.

Durante questo periodo, continueremo a seguire i consigli di Guido sulla migrazione: eseguendo 2to3 sulla nostra base di codice 2.xe modificando la base di codice 2.x per far passare i test in entrambe le versioni.

Il risultato è che Python 3.x non sarà una lingua fonte per Twisted fino a ben oltre il mio 35 ° compleanno & # 8212; sarà un runtime di destinazione (e un insieme di linee guida e restrizioni) per il mio codice python 2.x. Mi aspetto di scrivere programmi in Python 2.x per i prossimi dieci anni circa.

Quindi, questo è il piano. Spero che finisca per sembrare ridicolmente conservatore tra circa un anno; che la transizione 3.x è facile come una torta e che tutti si aggiornano rapidamente. Potrebbero accadere anche altre cose: i rami 2.xe 3.x potrebbero convergere, qualcuno potrebbe finire per scrivere un 3to2 o un altro runtime (mi viene in mente PyPy) potrebbe consentire l'esecuzione di 2.x e codice 3.x nello stesso processo direttamente, facilitando il nostro processo di conversione.

Per il momento, tuttavia, supponiamo che, per molti anni, avremo persone con basi di codice di grandi dimensioni che mantengono (o persone che scrivono nuovo codice che vogliono usare altre librerie che non sono ancora stati migrati) che desiderano ancora nuove funzionalità e correzioni di bug in Twisted. Molto presto mi aspetto che avremo anche utenti all'avanguardia che vogliono usare Twisted su Python 3. Mi piacerebbe offrire a tutte quelle persone un'esperienza positiva il più a lungo possibile.

Altri suggerimenti

Il progetto Django utilizza la libreria six per mantenere una base di codice che funzioni contemporaneamente su Python 2 e Python 3 ( post di blog ).

six fornisce un livello di compatibilità che reindirizza in modo intelligente le importazioni e le funzioni nelle rispettive posizioni (oltre a unificare altre modifiche incompatibili).

Vantaggi evidenti:

Non sono necessari rami separati per Python 2 e Python 3
Nessuno strumento di conversione, come 2to3.

L'idea principale di 2.6 è di fornire un percorso di migrazione a 3.0. Quindi puoi usare da __future__ import X eseguendo la migrazione lenta di una funzione alla volta fino a quando non li ottieni tutti inchiodati e puoi passare a 3.0. Molte delle funzionalità 3.0 passeranno anche alla 2.6, quindi puoi ridurre gradualmente il gap linguistico piuttosto che dover migrare tutto in una volta.

Al lavoro, prevediamo di aggiornare prima da 2.5 a 2.6. Quindi iniziamo ad abilitare lentamente le funzionalità 3.0 un modulo alla volta. Ad un certo punto un'intera sottoparte del sistema sarà probabilmente pronta per 3.x.

L'unico problema sono le librerie. Se una libreria non viene mai migrata, siamo bloccati con la vecchia libreria. Ma sono abbastanza fiducioso che avremo una valida alternativa a tempo debito per quella parte.

Parlando come autore di una biblioteca:

Sto aspettando il rilascio della versione finale. La mia convinzione, come quella della maggior parte della comunità Python, è che 2.x continuerà a essere la versione dominante per un periodo di settimane o mesi. È tutto il tempo per rilasciare una versione 3.x piacevole e raffinata.

Manterrò rami separati 2.xe 3.x. 2.x sarà retrocompatibile con la 2.4, quindi non posso usare molta sintassi elaborata o nuove funzionalità in 2.6 / 3.0. Al contrario, il ramo 3.x utilizzerà ciascuna di quelle funzionalità che si traducono in un'esperienza migliore per l'utente. La suite di test verrà modificata in modo che 2to3 funzioni su di essa e manterrò gli stessi test per entrambi i rami.

Supporta entrambi

Volevo fare un tentativo di convertire la libreria BeautifulSoup in 3x per un progetto a cui sto lavorando, ma vedo come sarebbe difficile mantenere due diversi rami del codice.

Il modello corrente per gestirlo include:

apporta una modifica al ramo 2x
esegui 2to3
prega che esegua correttamente la conversione la prima volta
esegui il codice
esegui test unitari per verificare che tutto funzioni
copia l'output nel ramo 3x

Questo modello funziona ma IMHO fa schifo. Per ogni modifica / rilascio devi seguire questi passaggi :: sigh ::. Inoltre, scoraggia gli sviluppatori dall'estendere il ramo 3x con nuove funzionalità che possono essere supportate solo in py3k perché stai ancora essenzialmente indirizzando tutto il codice a 2x.

La soluzione ... usa un preprocessore

Dato che non riuscivo a trovare un preprocessore decente in stile c con le direttive #define e #ifdef per Python ne ho scritto uno.

Si chiama pypreprocessor e può essere trovato nel PYPI

In sostanza, quello che fai è:

import pypreprocessor
rileva in quale versione di Python è in esecuzione lo script
imposta un 'define' nel preprocessore per la versione (ex 'python2' o 'python3')
cospargere le direttive '#ifdef python2' e '#ifdef python3' dove il codice è specifico della versione
esegui il codice

Questo è tutto. Ora funzionerà sia in 2x che in 3x. Se sei preoccupato per l'ulteriore aumento delle prestazioni nell'esecuzione di un preprocessore, c'è anche una modalità che eliminerà tutti i metadati e genererà la fonte post-elaborata su un file.

Meglio di tutto ... devi solo fare la conversione 2to3 una volta.

Ecco un esempio funzionante:

#!/usr/bin/env python
# py2and3.py

import sys
from pypreprocessor import pypreprocessor

#exclude
if sys.version[:3].split('.')[0] == '2':
    pypreprocessor.defines.append('python2')
if sys.version[:3].split('.')[0] == '3':
    pypreprocessor.defines.append('python3')

pypreprocessor.parse()
#endexclude
#ifdef python2
print('You are using Python 2x')
#ifdef python3
print('You are using python 3x')
#else
print('Python version not supported')
#endif

Questi sono i risultati nel terminale:

 python py2and3.py
 >>>You are using Python 2x 
 python3 py2and3.py
 >>>You are using python 3x

Se si desidera eseguire l'output su un file e creare un file sorgente specifico della versione pulito senza metadati aggiuntivi, aggiungere queste due righe da qualche parte prima dell'istruzione pypreprocessor.parse ():

pypreprocessor.output = outputFileName.py
pypreprocessor.removeMeta = True

Quindi:

python py2and3.py

Creerà un file chiamato outputFileName.py specifico per Python 2x senza metadati extra.

python3 py2and3.py

Creerà un file chiamato outputFileName.py che è specifico di Python 3x senza metadati extra.

Per la documentazione e altri esempi, consulta pypreprocessor su GoogleCode .

Spero sinceramente che questo aiuti. Adoro scrivere codice in Python e spero di vedere i progressi del supporto nel regno 3x appena possibile. Odio vedere la lingua non progredire. In particolare, poiché la versione 3x risolve molti WTF in primo piano e rende la sintassi un po 'più amichevole per gli utenti che migrano da altre lingue.

La documentazione a questo punto è completa ma non estesa. Cercherò presto di ottenere il wiki con alcune informazioni più ampie.

Aggiornamento:

Anche se ho progettato pypreprocessor appositamente per risolvere questo problema, non funziona perché il lexer verifica la sintassi su tutto il codice prima che venga eseguito qualsiasi codice.

Se python avesse un vero supporto per la direttiva preprocessore C consentirebbe agli sviluppatori di scrivere entrambi i codici python2x e python3k uno accanto all'altro nello stesso file ma a causa della cattiva reputazione del preprocessore C (abuso della sostituzione delle macro per cambiare lingua parole chiave) Non vedo presto il supporto legittimo del preprocessore C aggiunto a Python.

Zope Toolkit sta procedendo lentamente al supporto di Python 3. Rallenta principalmente perché molte di queste librerie sono molto complesse.

Per la maggior parte delle librerie uso 2to3. Alcune librerie ne fanno a meno perché sono semplici o hanno la maggior parte del codice in un'estensione C. zc.buildout, che è un pacchetto correlato, eseguirà lo stesso codice senza 2to3 per il supporto di Python 2 e 3.

Portiamo lo ZTK su Python 3 perché molte altre librerie e framework dipendono da esso, come Twisted e il framework Pyramid.

Alcuni dei miei codici 2.x più complessi rimarranno a 2.5 o 2.6. Sto passando a 3.0 per tutti i nuovi sviluppi una volta che alcune delle librerie di terze parti che utilizzo spesso sono state aggiornate per 3.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow