¿Cómo planea manejar la migración a Python 3?

Question

Estoy seguro de que este es un tema que está en la mente de la mayoría de los desarrolladores de Python considerando que Python 3 saldrá pronto. Algunas preguntas para llevarnos en la dirección correcta:

1. ¿Tendrás una versión de python 2 y python 3 para mantener al mismo tiempo o simplemente tendrás una versión de python 3 una vez que esté terminada?

   • ¿Ya has comenzado o planeas comenzar pronto? ¿O planeas esperar hasta que salga la versión final para entrar en pleno apogeo?

Answer 1

Aquí está el plan general para Twisted. Originalmente iba a bloguear esto, pero luego pensé: ¿por qué bloguear sobre eso cuando podía obtener puntos por ello?

1. Espere hasta que a alguien le importe.

   En este momento, nadie tiene Python 3. No vamos a gastar un montón de esfuerzo hasta que al menos un usuario real haya aparecido y dicho "Necesito soporte para Python 3.0", y tenga una buena razón para dejarlo de lado. por el hecho de que 3.0 se ve brillante.

2. Espere hasta que nuestras dependencias hayan migrado.

   Un sistema grande como Twisted tiene varias dependencias. Para empezar, las nuestras incluyen:

   • Interfaz Zope
   • PyCrypto
   • PyOpenSSL
   • pywin32
   • PyGTK (aunque esta dependencia es tristemente muy ligera en este momento, para cuando llegue la migración, espero Twisted tendrá más herramientas GUI)
   • pyasn1
   • PyPAM
   • gmpy

   Algunos de estos proyectos tienen su propio conjunto de dependencias, por lo que también tendremos que esperarlos.

3. Espere hasta que a alguien le importe lo suficiente para ayudar .

   Hay, caritativamente, 5 personas que trabajan en Twisted, y yo digo "caritativamente". porque eso me está contando, y no me he comprometido en meses. Tenemos más de 1000 tickets abiertos en este momento, y sería bueno arreglar algunos de esos & # 8212; corrige errores, agrega funciones y, en general, hace que Twisted sea un producto mejor por derecho propio & # 8212; antes de dedicar tiempo a transferirlo a una versión sustancialmente nueva del idioma.

   Esto potencialmente incluye a patrocinadores preocupados lo suficiente como para pagar para que lo hagamos, pero espero que habrá una afluencia de voluntarios que se preocupan por el apoyo 3.0 y desean ayudar a que la comunidad avance.

4. Sigue los consejos de Guido.

   Esto significa no cambiaremos nuestra API de manera incompatible , y seguiremos el desarrollo de transición pautas que Guido publicó el año pasado. Eso comienza con tener pruebas unitarias y ejecutar la herramienta de conversión 2to3 sobre la base de código Twisted.

5. Reportar errores y parches de archivos para la herramienta 2to3 .

   Cuando lleguemos al punto en el que realmente lo estamos usando, anticipo que habrá muchos problemas con la ejecución de 2to3 en el futuro. Ejecutarlo en Twisted en este momento lleva un tiempo extremadamente largo y (la última vez que lo comprobé, que fue hace bastante tiempo) no puede analizar algunos de los archivos en el repositorio de Twisted, por lo que la salida resultante no se importará. Creo que tendrá que haber una buena cantidad de historias de éxito de proyectos pequeños y un montón de martilleo en la herramienta antes de que realmente funcione para nosotros.

   Sin embargo, el equipo de desarrollo de Python ha sido muy útil para responder a nuestros informes de errores, y las respuestas iniciales a estos problemas han sido alentadoras, por lo que espero que todos estos problemas se solucionen a tiempo.

6. Mantenga la compatibilidad 2.x durante varios años.

   En este momento, Twisted admite Python 2.3 a 2.5. Actualmente, estamos trabajando en el soporte 2.6 (¡lo que obviamente tendremos que terminar antes del 3.0!). Nuestro plan es revisar nuestras versiones compatibles de Python basadas en las versiones compatibles a largo plazo de Ubuntu - la versión 8.04, que incluye Python 2.5, será compatible hasta 2013. Según el consejo de Guido, tendremos que abandonar la compatibilidad con 2.5 para admitir 3.0, pero espero que podamos encontrar una forma de evitarlo (somos bastante creativos con hacks de compatibilidad de versiones).

   Por lo tanto, estamos planeando admitir Python 2.5 hasta al menos 2013. En dos años, Ubuntu lanzará otra versión compatible de Ubuntu a largo plazo: si aún existen, y se mantienen en la fecha prevista, será 10.04. Personalmente, supongo que esto se enviará con Python 2.x, quizás python 2.8, como / usr / bin / python , porque hay una gran cantidad de software Python empaquetado con la distribución y tomará mucho tiempo para actualizarlo todo. Por lo tanto, cinco años después de luego , en 2015, podemos comenzar a considerar la eliminación del soporte 2.x.

   Durante este período, continuaremos siguiendo los consejos de Guido sobre la migración: ejecutar 2to3 sobre nuestra base de código 2.x, y modificar la base de código 2.x para que sus pruebas pasen en ambas versiones.

   El resultado de esto es que Python 3.x no será un idioma fuente para Twisted hasta mucho después de mi 35 cumpleaños & # 8212; será un tiempo de ejecución objetivo (y un conjunto de pautas y restricciones) para mi código python 2.x. Espero estar escribiendo programas en Python 2.x durante los próximos diez años más o menos.

Entonces, ese es el plan. Espero que termine pareciendo ridículamente conservador en aproximadamente un año; que la transición 3.x es fácil como un pastel, y todos se actualizan rápidamente. También podrían ocurrir otras cosas: las ramas 2.xy 3.x podrían converger, alguien podría terminar escribiendo un 3to2 , u otro tiempo de ejecución (PyPy me viene a la mente) podría permitir ejecutar 2.x y el código 3.x en el mismo proceso directamente, lo que hace que nuestro proceso de conversión sea más fácil.

Por el momento, sin embargo, estamos asumiendo que, durante muchos años, tendremos personas con bases de código grandes que están manteniendo (o personas que escriben código nuevo que quieren usar otras bibliotecas que aún no se han migrado) que aún desean nuevas características y correcciones de errores en Twisted. Muy pronto espero que también tengamos usuarios avanzados que quieran usar Twisted en Python 3. Me gustaría proporcionar a todas esas personas una experiencia positiva durante el mayor tiempo posible.

Answer 2

El proyecto Django usa la biblioteca six para mantener un código base que funcione simultáneamente en Python 2 y Python 3 ( publicación de blog ).

six hace esto al proporcionar una capa de compatibilidad que redirige de manera inteligente las importaciones y funciones a sus ubicaciones respectivas (así como también unifica otros cambios incompatibles).

Ventajas obvias:

• No es necesario tener ramas separadas para Python 2 y Python 3
• Sin herramientas de conversión, como 2to3.

Answer 3

La idea principal de 2.6 es proporcionar una ruta de migración a 3.0. Por lo tanto, puede usar from __future__ import X migrando lentamente una característica a la vez hasta que las consiga todas y pueda pasar a 3.0. Muchas de las características 3.0 también fluirán a 2.6, por lo que puede reducir la brecha de idioma gradualmente en lugar de tener que migrar todo de una vez.

En el trabajo, planeamos actualizar de 2.5 a 2.6 primero. Entonces comenzamos a habilitar las características 3.0 lentamente, un módulo a la vez. En algún momento, toda una parte del sistema estará lista para 3.x.

El único problema son las bibliotecas. Si una biblioteca nunca se migra, estamos atascados con la biblioteca anterior. Pero estoy bastante seguro de que obtendremos una buena alternativa a su debido tiempo para esa parte.

Answer 4

Hablando como autor de una biblioteca:

Estoy esperando que se lance la versión final. Mi creencia, como la de la mayoría de la comunidad de Python, es que 2.x continuará siendo la versión dominante durante un período de semanas o meses. Es tiempo de sobra para lanzar una versión 3.x agradable y pulida.

Mantendré ramas separadas 2.xy 3.x. 2.x será compatible con versiones anteriores a 2.4, por lo que no puedo usar gran parte de la sintaxis o las nuevas funciones de 2.6 / 3.0. Por el contrario, la rama 3.x utilizará cada una de esas características que resultan en una mejor experiencia para el usuario. El conjunto de pruebas se modificará para que 2to3 funcione sobre él, y mantendré las mismas pruebas para ambas ramas.

Answer 5

Soporta ambos

Quería intentar convertir la biblioteca BeautifulSoup a 3x para un proyecto en el que estoy trabajando, pero puedo ver cómo sería difícil mantener dos ramas diferentes del código.

El modelo actual para manejar esto incluye:

1. haz un cambio en la rama 2x
2. ejecutar 2to3
3. reza para que haga la conversión correctamente la primera vez
4. ejecuta el código
5. ejecute pruebas unitarias para verificar que todo funcione
6. copie la salida a la rama 3x

Este modelo funciona pero en mi humilde opinión es una mierda. Para cada cambio / lanzamiento, debe seguir estos pasos :: suspiro ::. Además, disuade a los desarrolladores de ampliar la rama 3x con nuevas características que solo se pueden admitir en py3k porque, en esencia, aún está orientando todo el código a 2x.

La solución ... usa un preprocesador

Como no pude encontrar un preprocesador decente estilo c con las directivas #define y #ifdef para python, escribí una.

Se llama pypreprocessor y se puede encontrar en el PYPI

Esencialmente, lo que haces es:

1. import pypreprocessor
2. detectar en qué versión de Python se ejecuta el script
3. establezca un 'define' en el preprocesador para la versión (ex 'python2' o 'python3')
4. rocíe las directivas '#ifdef python2' y '#ifdef python3' donde el código es específico de la versión
5. ejecuta el código

Eso es todo. Ahora funcionará en 2x y 3x. Si le preocupa el aumento en el rendimiento de la ejecución de un preprocesador, también hay un modo que eliminará todos los metadatos y generará la fuente procesada en un archivo.

Lo mejor de todo ... solo tiene que hacer la conversión 2to3 una vez.

Aquí está el ejemplo de trabajo:

#!/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

Estos son los resultados en el terminal:

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

Si desea exportar a un archivo y crear un archivo fuente limpio específico de la versión sin metadatos adicionales, agregue estas dos líneas en algún lugar antes de la declaración pypreprocessor.parse ():

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

Entonces:

python py2and3.py

Creará un archivo llamado outputFileName.py que es específico de python 2x sin metadatos adicionales.

python3 py2and3.py

Creará un archivo llamado outputFileName.py que es específico de python 3x sin metadatos adicionales.

Para obtener documentación y más ejemplos, consulte pypreprocessor en GoogleCode .

Espero sinceramente que esto ayude. Me encanta escribir código en python y espero ver el progreso del soporte en el reino 3x lo antes posible. Odio ver que el lenguaje no progrese. Especialmente, ya que la versión 3x resuelve muchos de los WTF destacados y hace que la sintaxis parezca un poco más amigable para los usuarios que migran desde otros idiomas.

La documentación en este punto está completa pero no es extensa. Intentaré obtener el wiki con información más extensa pronto.

Update:

Aunque diseñé pypreprocessor específicamente para resolver este problema, no funciona porque el lexer verifica la sintaxis de todo el código antes de que se ejecute ningún código.

Si Python tuviera soporte real de directivas de preprocesador C, permitiría a los desarrolladores escribir código python2x y python3k uno junto al otro en el mismo archivo pero debido a la mala reputación del preprocesador C (abuso de reemplazo de macro para cambiar el lenguaje palabras clave) No veo soporte de preprocesador C legítimo agregado a Python en el corto plazo.

Answer 6

El kit de herramientas de Zope ha avanzado lentamente hacia la compatibilidad con Python 3. Lento principalmente porque muchas de estas bibliotecas son muy complejas.

Para la mayoría de las bibliotecas, uso 2to3. Algunas bibliotecas no pueden hacerlo porque son simples o tienen la mayor parte del código en una extensión-C. zc.buildout, que es un paquete relacionado, ejecutará el mismo código sin 2to3 para el soporte de Python 2 y 3.

Transportamos el ZTK a Python 3 porque muchas otras bibliotecas y marcos dependen de él, como Twisted y el marco Pyramid.

Answer 7

Algunos de mis códigos 2.x más complejos se quedarán en 2.5 o 2.6. Estoy cambiando a 3.0 para todos los desarrollos nuevos una vez que algunas de las bibliotecas de terceros que utilizo a menudo se hayan actualizado para 3.