python - migrations - para que sirven las migraciones en django

¿Cómo planeas manejar la migración a Python 3? (7)

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 ayudarnos a avanzar en la dirección correcta:

¿Tendrá una versión de python 2 y python 3 para mantener al mismo tiempo o simplemente tendrá una versión de python 3 una vez que haya finalizado?
- ¿Ya comenzó o planea comenzar pronto? ¿O planeas esperar hasta que la versión final salga para entrar en pleno desarrollo?

Apoye ambos

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

El modelo actual para manejar esto incluye:

hacer un cambio en la rama 2x
ejecutar 2to3
ore para que haga la conversión correctamente la primera vez
ejecuta el código
ejecutar pruebas unitarias para verificar que todo funcione
copiar la salida a la rama 3x

Este modelo funciona pero en mi humilde opinión es una mierda. Para cada cambio / versión, debe seguir estos pasos :: suspiro ::. Además, desalienta a los desarrolladores a extender la rama 3x con nuevas características que solo pueden ser soportadas en py3k porque todavía estás apuntando esencialmente a todo el código a 2x.

La solución ... usa un preprocesador

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

Se llama pypreprocessor y se puede encontrar en el PYPI

Esencialmente, lo que haces es:

pypreprocessor de importación
detectar en qué versión de python se está ejecutando el script
establecer un ''definir'' en el preprocesador para la versión (ex ''python2'' o ''python3'')
espolvorear las directivas ''#ifdef python2'' y ''#ifdef python3'' donde el código es específico de la versión
ejecuta el código

Eso es. Ahora funcionará tanto en 2x como en 3x. Si le preocupa el rendimiento agregado al ejecutar un preprocesador, también hay un modo que borrará todos los metadatos y generará el origen postprocesado en un archivo.

Lo mejor de todo ... solo tienes 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 la terminal:

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

Si desea exportar a un archivo y hacer un archivo fuente limpio y específico de la versión sin metadatos adicionales, agregue estas dos líneas en algún lugar antes de la instrucció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 el proceso de pypreprocessor en GoogleCode .

Sinceramente espero que esto ayude. Me encanta escribir código en python y espero ver progreso de soporte en el reino de 3x lo antes posible. Odio ver que el idioma no progrese. Especialmente, dado que la versión 3x resuelve muchas de las WTF presentadas y hace que la sintaxis parezca un poco más amigable para los usuarios que migran de otros idiomas.

La documentación en este momento es completa pero no extensa. Trataré de subir la wiki con información más extensa pronto.

Actualizar:

Aunque diseñé el Pypreprocessor específicamente para resolver este problema, no funciona porque el lexer comprueba la sintaxis en todo el código antes de que se ejecute cualquier código.

Si python tuviera compatibilidad con directivas de preprocesador C reales, les permitiría a los desarrolladores escribir tanto python2x como python3k uno junto al otro en el mismo archivo, pero debido a la mala reputación del preprocesador C (abuso de macrosustitución para cambiar palabras clave de idioma) no ver soporte de preprocesador C legítimo que se agrega a python en el corto plazo.

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

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 haya aparecido y haya dicho "Necesito el soporte de Python 3.0", y tiene una buena razón para ello aparte del hecho de que 3.0 se ve brillante.
Espere hasta que nuestras dependencias hayan migrado.
Un sistema grande como Twisted tiene varias dependencias. Para empezar, los nuestros incluyen:
- Interfaz Zope
- PyCrypto
- PyOpenSSL
- pywin32
- PyGTK (aunque esta dependencia es lamentablemente muy ligera en este momento, para cuando la migración llegue, espero que Twisted tenga más herramientas GUI)
- pyasn1
- PyPAM
- gmpy
Algunos de estos proyectos tienen su propia gama de dependencias, por lo que tendremos que esperar también.
Espera a que alguien se preocupe lo suficiente como para ayudar .
Hay, caritativamente, 5 personas que trabajan en Twisted, y 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 solucionar algunos de ellos, corregir errores, agregar funciones y, por lo general, convertir a Twisted en un mejor producto por derecho propio antes de dedicar tiempo a transferirlo a un sitio sustancialmente. nueva versión del lenguaje.
Esto potencialmente incluye sponsors preocupan lo suficiente como para pagar por nosotros, pero espero que haya una afluencia de voluntarios que se preocupan por el apoyo 3.0 y quieran ayudar a la comunidad a avanzar.
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 tener pruebas unitarias y ejecutar la herramienta de conversión 2to3 sobre la base de código Twisted.
Informe 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 mucho tiempo y (la última vez que lo comprobé, 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 pequeños proyectos y mucho 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 primeras respuestas a estos problemas han sido alentadoras, por lo que espero que todos estos problemas se solucionen a tiempo.
Mantenga la compatibilidad 2.x durante varios años.
En este momento, Twisted admite python 2.3 a 2.5. Actualmente, estamos trabajando en soporte 2.6 (¡que obviamente tendremos que terminar antes de 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 dejar de recibir soporte para 2.5 en orden para admitir 3.0, pero espero que podamos encontrar una forma de evitarlo (somos bastante creativos con los hacks de compatibilidad de versiones).
Por lo tanto, planeamos admitir Python 2.5 hasta al menos 2013. En dos años, Ubuntu lanzará otra versión compatible de Ubuntu a largo plazo: si todavía existen, y se mantienen dentro del cronograma, será 10.04. Personalmente, estoy adivinando que esto se enviará con Python 2.x, quizás con Python 2.8, como /usr/bin/python , porque hay una gran cantidad de software Python empaquetado con la distribución y llevará mucho tiempo actualizarlo todo . Entonces, dentro de cinco años, en 2015, podemos empezar a buscar una reducción del soporte de 2.x.
Durante este período, seguiremos los consejos de Guido sobre migración: ejecute 2to3 sobre nuestra base de código 2.x y modifiquemos la base de código 2.x para que las pruebas pasen en ambas versiones.
El resultado de esto es que Python 3.x no será un idioma de origen para Twisted hasta mucho después de mi 35º cumpleaños: 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 un año más o menos; 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 ramas 2.x y 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 del código 2.x y 3.x en el mismo proceso directamente, facilitando nuestro proceso de conversión.

Por el momento, sin embargo, asumimos que, durante muchos años, tendremos personas con grandes bases de código que mantienen (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 novedosos que quieran usar Twisted on python 3. Me gustaría brindar a todas esas personas una experiencia positiva el mayor tiempo posible.

El kit de herramientas Zope ha progresado lentamente hasta el soporte de Python 3. Lenta principalmente porque muchas de estas bibliotecas son muy complejas.

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

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

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 al proporcionar una capa de compatibilidad que redirige de manera inteligente importaciones y funciones a sus respectivas ubicaciones (así como también unifica otros cambios incompatibles).

Ventajas evidentes:

No hay necesidad de ramas separadas para Python 2 y Python 3
Sin herramientas de conversión, como 2to3.

Hablando como autor de la biblioteca:

Estoy esperando que se publique 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 por un período de semanas o meses. Es tiempo de sobra para lanzar una bonita y pulida versión 3.x.

Mantendré ramas 2.x y 3.x separadas. 2.x será retrocompatible con 2.4, por lo que no puedo usar mucha de la sintaxis sofisticada o nuevas características en 2.6 / 3.0. Por el contrario, la sucursal 3.x utilizará cada una de esas características que resultan en una experiencia más agradable para el usuario. El conjunto de pruebas se modificará para que 2to3 trabaje sobre él, y mantendré las mismas pruebas para ambas ramas.

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 todas from __future__ import X y puedan moverse a 3.0. Muchas de las características 3.0 fluirán también a 2.6, por lo que puede hacer que la brecha de idioma sea más pequeña gradualmente en lugar de tener que migrar todo de una vez.

En el trabajo, planeamos actualizar de 2.5 a 2.6 primero. Luego comenzamos a habilitar las características 3.0 lentamente, un módulo a la vez. En algún momento, toda una subparte 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 anterior. Pero estoy bastante seguro de que obtendremos una buena alternativa a su debido tiempo para esa parte.

Parte de mi código 2.x más complejo se quedará en 2.5 o 2.6. Paso a 3.0 para todos los nuevos desarrollos una vez que algunas de las bibliotecas de terceros que uso a menudo se hayan actualizado para 3.