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

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á una versión de python 2 y python 3 para mantener simultáneamente o simplemente tendrá una versión de python 3 una vez que esté terminada?

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

Aquí está el plan general para Twisted. Originalmente iba a bloguear esto, pero luego pensé: ¿por qué blog acerca de cuándo podría obtener puntos por ello?

  1. Espera 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 aparezca y diga “Necesito asistencia de Python 3.0”, y tiene una buena razón para ello, aparte del hecho de que 3.0 se ve shiny.

  2. Espera 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, lamentablemente, muy ligera en este momento, para cuando la migración haya comenzado, espero que Twisted tenga más herramientas de GUI)
    • pyasn1
    • PyPAM
    • gmpy

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

  3. Espera 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 cuenta y no me he comprometido en meses. Tenemos más de 1000 tickets abiertos en este momento, y sería bueno corregir algunos de ellos: corregir errores, agregar funciones y, en general, hacer que Twisted sea un producto mejor por sí mismo, antes de dedicar tiempo a que sea transferido a un Nueva versión del lenguaje.

    Esto potencialmente incluye a los patrocinadores que se preocupan lo suficiente como para pagarnos para que lo hagamos, pero espero que haya una afluencia de voluntarios que se preocupen por el apoyo 3.0 y quieran ayudar a que la comunidad avance.

  4. Sigue los consejos de Guido.

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

  5. Reporte errores y parches para la herramienta 2to3 .

    Cuando lleguemos al punto en el que realmente lo estemos usando, anticipo que habrá muchos problemas con la ejecución de 2to3 en el futuro. Ejecutarlo en Twisted ahora lleva mucho tiempo y (la última vez que lo comprobé, que fue hace bastante tiempo) no se pueden analizar algunos de los archivos en el repository de Twisted, por lo que la salida resultante no se importará. Creo que tendrá que haber una buena cantidad de historias de éxito de pequeños proyectos 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 de gran ayuda para responder a nuestros informes de errores, y las respuestas tempranas a estos problemas han sido alentadoras, por lo que espero que todos estos problemas se solucionen a tiempo.

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

    En este momento, Twisted soporta 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 soportadas a largo plazo de Ubuntu – la versión 8.04, que incluye Python 2.5, será compatible hasta 2013. De acuerdo con el consejo de Guido, deberemos retirar el soporte para 2.5 para para la versión 3.0, pero espero que podamos encontrar una manera de solucionarlo (somos bastante creativos con los 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 soportada a largo plazo de Ubuntu: si aún existen, y se mantendrán en el progtwig, eso 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 de Python empaquetado con la distribución y tomará mucho tiempo actualizarlo todo. . Entonces, cinco años a partir de entonces , en 2015, podemos empezar a analizar la posibilidad de abandonar el soporte 2.x.

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

    El resultado de esto es que Python 3.x no será un idioma de origen de Twisted hasta mucho después de mi cumpleaños número 35; será un tiempo de ejecución de destino (y un conjunto de pautas y restricciones) para mi código de python 2.x. Espero estar escribiendo progtwigs en Python 2.x durante los próximos diez años.

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 suceder otras cosas: las twigs 2.xy 3.x podrían converger, alguien podría terminar escribiendo un 3to2 , u otro tiempo de ejecución (PyPy viene a la mente) podría permitir la ejecución de códigos 2.xy 3.x en el mismo proceso directamente, facilitando nuestro proceso de conversión.

Sin embargo, por el momento, estamos asumiendo que, durante muchos años, tendremos personas con grandes bases de código que están manteniendo (o personas que escriben código nuevo que desean 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 brindarles a todas esas personas una experiencia positiva durante el mayor tiempo posible.

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

six hace esto proporcionando una capa de compatibilidad que redirige de manera inteligente las importaciones y funciones a sus ubicaciones respectivas (así como unificando otros cambios incompatibles).

Ventajas obvias:

  • No se necesitan twigs separadas para Python 2 y Python 3
  • No hay herramientas de conversión, como 2to3.

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 función a la vez hasta que las tenga todas en lata y pueda pasar a la from __future__ import X 3.0. Muchas de las características de la versión 3.0 también se integrarán en la versión 2.6, por lo que puede reducir gradualmente la brecha de idioma 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 punto, una subparte completa del sistema probablemente estará lista para 3.x.

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

Hablando como autor de la biblioteca:

Estoy esperando a que salga 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. Eso es un montón de tiempo para lanzar una versión agradable, pulida 3.x.

Mantendré twigs separadas de 2.xy 3.x. 2.x será compatible con versiones anteriores a 2.4, por lo que no puedo usar gran parte de la syntax o las nuevas funciones de 2.6 / 3.0. En contraste, la twig 3.x utilizará cada una de esas características que resultarán en una mejor experiencia para el usuario. El conjunto de pruebas se modificará para que 2to3 funcione, y mantendré las mismas pruebas para ambas sucursales.

Apoyar a ambos

Quería hacer un bash de 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 twigs diferentes del código.

El modelo actual para manejar esto incluye:

  1. hacer un cambio a la twig 2x
  2. corre 2to3
  3. Oremos para que haga la conversión correctamente la primera vez.
  4. ejecuta el código
  5. Ejecutar pruebas unitarias para verificar que todo funciona.
  6. Copia la salida a la twig 3x.

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

La solución … usar 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. pypreprocessor de importación
  2. Detectar en qué versión de Python se ejecuta el script.
  3. establecer una ‘definir’ 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. Ahora funcionará tanto en 2x como en 3x. Si le preocupa el aumento en el rendimiento de ejecutar 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 tienes que hacer la conversión 2to3 una vez.

Aquí está un 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
  >>> Estás usando Python 2x 
  python3 py2and3.py
  >>> Estás usando python 3x

Si desea generar un archivo y limpiar un archivo fuente específico de la versión sin metadatos adicionales, agregue estas dos líneas en algún lugar antes de la statement 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 ver la documentación y más ejemplos, consulte la página sobre el procesador de datos en GoogleCode .

Sinceramente espero que esto ayude. Me encanta escribir código en python y espero ver progreso de soporte en el ámbito 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 syntax 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é hacer que la wiki aparezca más extensa pronto.

Actualizar:

Aunque diseñé pypreprocessor específicamente para resolver este problema, no funciona porque el lexer realiza la comprobación de syntax en todo el código antes de que se ejecute cualquier código.

Si Python tuviera soporte real de directivas de preprocesador C, permitiría a los desarrolladores escribir ambos códigos python2x y python3k uno al lado del otro en el mismo archivo, pero debido a la mala reputación del preprocesador C (abuso del reemplazo de macros para cambiar las palabras clave del idioma) vea el soporte legítimo del preprocesador de C que se agregará a Python en el corto plazo.

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

Para la mayoría de las bibliotecas utilizo 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 la compatibilidad con Python 2 y 3.

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

Parte de mi código 2.x más complejo se mantendrá 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.