Para la conversión de código Python2 a Python3, ¿qué versión de Python & Django es la más adecuada?

Actualmente estoy trabajando en una gran empresa donde necesitamos convertir el antiguo proyecto Django de python2 a la versión python3, por lo que he investigado mucho pero aún no he podido encontrar una respuesta perfecta relacionada con la versión de Python y Django más adecuada para la conversión.

Actualmente estoy usando Python: 2.7.16 y Django: 1.9.13 en mi versión anterior.

Cualquiera puede sugerirme la versión más adecuada de Python y Django para la versión anterior para la conversión de python2 a python3.

Pensé agregar un poco a la estrategia defendida por la respuesta de Wim: obtener la versión adecuada de Django trabajando primero en 2.7 y 3.x, y describir algunas tácticas que funcionaron para mí.

Python 2.7 es tu cápsula de escape, hasta que aprietes el gatillo en 3.x

• sus pruebas deben ejecutarse en ambos
• no use ninguna característica específica de 3.x, como f-strings
• primero Python 3.x, luego solo luego Django 2.x que no se ejecuta en 2.7
• Comience temprano, no analice en exceso, pero evite el enfoque del Big Bang
  • archivo por archivo al principio.
  • comience con el código de nivel más bajo, como las bibliotecas de utilidades, para las que tiene suites de pruebas.
  • si es posible, intente fusionar gradualmente sus cambios en las ramas de producción 2.7 y mantenga actualizado su código de transferencia 3.x con los cambios de producción.

¿Con qué versión menor de Django para empezar?

Mi criterio aquí es que las migraciones de Django pueden estar bastante involucradas (y en realidad requieren más reflexión que 2 => 3 trabajos). Así que me trasladaría al 1.11 más reciente y mejor de esa manera, ya está proporcionando algo de valor a sus 2.7 usuarios. Probablemente haya una buena cantidad de cuñas de compatibilidad anteriores a 2.x en 1.11 y recibirá sus advertencias de desaprobación 2.x.

¿Con qué versión menor de Python 3.x comenzar?

Es mejor tener en cuenta todos los ángulos, como la disponibilidad de sus librerías de terceros, el soporte de su suite CI / devops y la disponibilidad en las imágenes del sistema operativo de su servidor elegido. Siempre puede instalar 3.8 e intentar una instalación pip de su require.txt solo, por ejemplo.

Aproveche git (o cualquier scm que use) y virtualenv .

• separar requirement.txtarchivos , pero ...
• si tiene un repositorio git basado en archivos, puede apuntar cada venv a la misma línea de código con un pip install -e <your directory>. eso significa que, en 2 terminales diferentes, puede ejecutar 2.7 y 3.x contra las mismas pruebas unitarias.
• incluso podría ejecutar servidores Django 2.7 y 3.x lado a lado en diferentes puertos y señalar, por ejemplo, Firefox y Chrome.
• comprometerse a menudo (al menos en la rama portadora) y aprender sobre git bisect .

hacer uso de 2to3

Sí, romperá el código 2.7 y Django si lo dejas. Entonces...

• ejecútelo en modo de vista previa o en un solo archivo. vea lo que se rompe pero también vea lo que hizo bien.

• limítelo solo a ciertas conversiones que no rompan 2.7 o Django. print x=> print (x)y except(Exception) as eson 2 no-brainers.

Así es como se veía mi comando estrangulado:

2to3 $tgt -w -f except -f raise -f next -f funcattrs -f print

• ejecútelo archivo por archivo hasta que esté realmente seguro.

use sed o awk en lugar de su editor para conversiones masivas.

La ventaja es que, a medida que se vuelve más consciente de las preocupaciones específicas de sus aplicaciones, puede crear un conjunto de cambios que se pueden ejecutar en 1 archivo o en muchos archivos y hacer la mayor parte del trabajo sin romper 2.7 o Django. Aplique esto después de su pase 2to3 adecuadamente acelerado . Eso te deja con limpiezas residuales en tu editor y haciendo que tus pruebas pasen.

(opcional) comience a ejecutarse en negro en el código 2.7.

black, que es un formateador de código, usa Python 3 AST para ejecutar su análisis. No intenta ejecutar el código, pero marcará los errores de sintaxis que impiden que llegue a la etapa AST. Sin embargo, tendrás que trabajar con la magia global de instalación de pip para llegar allí y debes comprar la utilidad de las negras.

Otras personas lo han hecho, aprende de ellos.

Escuchar # 155 Pasos prácticos para pasar a Python 3 debería darle algunas ideas del trabajo. Mira los enlaces del programa. Les encanta hablar sobre el movimiento de Instagram (?) Que involucró un ajuste gradual de la ejecución del código 2.7 a la sintaxis 3.x en una base de código común y en la misma rama git, hasta el día de apretar el gatillo.

Consulte también la Guía de portabilidad conservadora de Python 3

e Instagram hacen un movimiento suave a Python 3 - The New Stack

Conclusión

Su tiempo para Django 1.11 EOL (abril de 2020) es bastante corto, por lo que si tiene más de 2 recursos de desarrollo para lanzar, consideraría hacer lo siguiente en paralelo:

• DEV # 1: comience con un golpe Django 1.11 (la teoría es que Django 1.11 probablemente esté mejor posicionado como un punto de partida para Django 2.x), usando 2.7.

• DEV # 2: comience en Python 3.6 / 3.7 de su código de utilidad que no sea Django. Como el código es compatible con 2.7 en este punto, combínelo en el # 1 a medida que avanza.

Vea cómo proceden ambas tareas, evalúe cuál es el riesgo del proyecto relacionado con Django y cómo se ve el dolor de Python 3. Ya te estás perdiendo la EOL de Python 2.7, pero un marco web obsoleto es probablemente más peligroso que el Python 2.7 heredado, al menos durante unos meses. Por lo tanto, no esperaría demasiado para comenzar a migrar de Django 1.9 y su trabajo al hacerlo no se desperdiciará. A medida que vea el progreso, comenzará a ver mejor los riesgos del proyecto.

Su progreso inicial de 2 a 3 será lento, pero las herramientas y la orientación son lo suficientemente buenas como para que aumente rápidamente la velocidad, así que no piense demasiado antes de comenzar a acumular experiencia. El lado de Django depende de su exposición a cambios importantes en el marco, por lo que creo que es mejor comenzar temprano.

PD (opinión controvertida / personal) No usé seis u otras bibliotecas puente de 2 a 3 enlatadas.

Sus no porque no me fío de ella - es brillante en las librerías de 3 ª parte - sino más bien que no quería añadir una dependencia permanente compleja (y yo era demasiado perezoso para leer su doc). Había estado escribiendo código 2.7 en sintaxis compatible 3.x durante mucho tiempo, así que realmente no sentía la necesidad de usarlos. Su kilometraje puede variar y no se inicie en este camino si parece mucho trabajo .

En cambio, creé un py223.py (57 LOC con comentarios incluidos) con este tipo de contenido, la mayoría de los cuales se refiere a soluciones para desaprobaciones y cambios de nombre en la biblioteca estándar.

try:
    basestring_ = basestring
except (NameError,) as e:
    basestring_ = str

try:
    cmp_ = cmp
except (NameError,) as e:
    # from http://portingguide.readthedocs.io/en/latest/comparisons.html
    def cmp_(x, y):
        """
        Replacement for built-in function cmp that was removed in Python 3
        """
        return (x > y) - (x < y)

Luego importe desde ese py223 para solucionar esas preocupaciones específicas. Más tarde me se acaba de deshacerse de la importación y mover los extraño isinstance(x, basestr_)a isinstance(x, str)pero sé de antemano que hay poco de qué preocuparse.

Mi sugerencia es actualizar primero a Django==1.11.26 , que es la versión más reciente de Django que es compatible con Python 2 y Python 3. Permanezca en su versión actual de Python 2.7 por ahora.

Lea atentamente las notas de la versión 1.10.xy 1.11.x, compruebe si hay desaprobaciones y arregle todo lo que dejó de funcionar desde su código 1.9.x. Las cosas se romperán. Django se mueve rápido. Para un proyecto grande de Django, es posible que se requieran muchos cambios de código, y si está utilizando una gran cantidad de complementos o bibliotecas de terceros, es posible que tenga que hacer malabarismos con sus versiones. Es probable que algunas de sus dependencias de terceros hayan sido abandonadas por completo, por lo que debe buscar reemplazos o eliminar las funciones.

Para encontrar las notas de la versión para cada actualización de la versión, simplemente busque "Novedades en Django". Los resultados documentarán meticulosamente todas las degradaciones y cambios:

• https://docs.djangoproject.com/en/2.2/releases/1.10/
• https://docs.djangoproject.com/en/2.2/releases/1.11/

Una vez que la aplicación web parece funcionar bien en Django 1.11, con todas las pruebas aprobadas (lo hace tiene un conjunto de pruebas, verdad?), Entonces puede hacer la conversión de Python 3, manteniendo la versión de Django igual. Django 1.11 admite hasta Python 3.7, por lo que sería una buena versión para apuntar. Espere unicode por todas partes, ya que las conversiones implícitas entre bytes y texto se han ido ahora y muchas aplicaciones web de Python 2 se basaron en eso.

Una vez que el proyecto parece estar funcionando bien en Django 1.11 y Python 3.7, puede pensar en actualizar a Django 3.0, siguiendo el mismo proceso que antes: leyendo las notas de la versión, realizando los cambios necesarios, ejecutando el conjunto de pruebas y revisando la aplicación web en un servidor de desarrollo de forma manual.

Me actualizaría a py3 primero. Tendrá que mirar setup.pyen el repositorio de Django en la rama estable / 1.9.x ( https://github.com/django/django/blob/stable/1.9.x/setup.py ) para descubrir que el py3 Las versiones admitidas son 3.4 (muerto) y 3.5.

Una vez que esté en py3.5 y Django 1.9, puede actualizar uno a la vez hasta llegar a la versión en la que desea finalizar. Por ejemplo, Django 1.11 admite py3.5 y py3.7, por lo que

py27/dj19 -> py35/dj19 -> py35/dj1.11 -> py37/dj1.11 ... -> py37/dj2.2

dj2.2 es la primera versión que admite py3.8, pero probablemente me detendría en py37 / dj2.2 si está trabajando en un entorno normalmente conservador.

Si tiene otros paquetes, necesitará encontrar combinaciones de versiones que funcionen juntas en cada paso. Tener un plan es clave, y actualizar solo un componente a la vez generalmente terminará ahorrándole tiempo.

La futura biblioteca ( https://python-future.org/ ) lo ayudará con muchas situaciones difíciles mientras necesita código para ejecutarse en py27 y 3.x. seis también es genial. Evitaría rodar su propia capa de compatibilidad (¿por qué reinventar la rueda?)

Si es posible, intente obtener una cobertura de prueba de la unidad de hasta el 75-85% antes de comenzar, y definitivamente configure las pruebas automáticas en las versiones "desde" y "a" para cada paso de actualización. Asegúrese de leer y corregir todas las advertencias de Django antes de actualizar a la próxima versión: Django se preocupa muy poco por la compatibilidad con versiones anteriores, por lo que normalmente sugeriría presionar cada versión menor en la ruta de actualización (o al menos asegúrese de leer "al revés" incompatibilidades "y listas de desaprobación para cada versión menor).

Buena suerte (estamos actualizando una base de código de 300+ Kloc desde py27 / dj1.7 en este momento, así que siento tu dolor ;-)

Tengo el mismo tipo de problema con mi proyecto y probé Python 3.7.5 con Django versión 2.2.7.

No debe usar la última versión de Python 3.8 o la última versión de Django 3.0 porque puede haber posibilidades de que para cualquier tipo de error no pueda obtener la solución adecuada para las últimas versiones.

Debes intentar disparar para las versiones actuales. Python 3.8 y Django 3.0. La biblioteca Six ayudará con algunos cambios en la convención. De cualquier manera, tendrá que hacer algunas refactorizaciones, por lo que también podría actualizarlas.