¿En qué versión de Python (2.4, 2.5, 2.6, 3.0) se estandariza para los esfuerzos de desarrollo de producción (y por qué)?

Question

En nuestro grupo, principalmente hacemos trabajo de integración de contenido y arquitectura de motores de búsqueda y la mayor parte de ese código base está en Python. Todas nuestras herramientas de compilación y las dependencias de los módulos de Python se encuentran en el control de origen, por lo que se pueden verificar y el entorno se puede cargar para su uso independientemente de la plataforma / sistema operativo, algo similar al enfoque virtualenv utiliza.

Durante años, hemos mantenido una base de código compatible con Python 2.3 porque uno de los productos comerciales que utilizamos depende de Python 2.3. A lo largo de los años, esto ha causado más y más problemas a medida que las nuevas herramientas y bibliotecas necesitan nuevas versiones de Python desde que se lanzó la versión 2.3 en 2004.

Recientemente hemos desacoplado nuestro entorno de compilación de las dependencias del entorno del producto comercial y podemos usar cualquier versión de Python (o Java) que queramos. Ha pasado aproximadamente un mes desde que estandarizamos Python 2.6 como la versión más reciente de Python que es compatible con versiones anteriores.

Python 3.0 no es una opción (por ahora) ya que tendríamos que migrar demasiado de nuestra base de código para que nuestras herramientas de compilación e integración funcionen correctamente nuevamente.

Nos gustan muchas de las nuevas características de Python 2.6, especialmente los módulos mejorados y cosas como los decoradores de clase, pero muchos módulos de los que dependemos hacen que el intérprete de Python 2.6 emita varias advertencias de depreciación. Otra herramienta que nos interesa para administrar los nodos de clúster en la nube de EC2, Supervisor ni siquiera funciona correctamente con Python 2.6.

Ahora me pregunto si deberíamos estandarizar Python 2.5 por ahora en lugar de usar Python 2.6 en el desarrollo de herramientas de entorno de producción. La mayoría de las herramientas que queremos / necesitamos parecen funcionar correctamente con Python 2.5. Estamos tratando de solucionar esto ahora antes de que haya muchas dependencias en las características o módulos de Python 2.6.

Muchas gracias!

-Michael

Answer 1

No abandonaría 2.6 solo por las advertencias de desaprobación; esos desaparecerán con el tiempo. (Puede usar la opción -W ignore para el intérprete de Python para evitar que se impriman, al menos). Pero si los módulos que necesita usar en realidad no funcionan con Python 2.6, eso sería Una razón legítima para quedarse con 2.5. Python 2.5 está en uso generalizado ahora y probablemente lo estará por mucho tiempo (¡considere cuánto tiempo ha durado 2.3!), Por lo que incluso si usa 2.5, no se verá obligado a actualizar por un tiempo.

Uso Python 2.5 para todo mi trabajo de desarrollo, pero solo porque es la versión que está disponible en el repositorio de paquetes de Gentoo (Linux). Cuando los mantenedores de Gentoo declaren Python 2.6 " estable " * , cambiaré a eso. Por supuesto, este razonamiento no necesariamente se aplicaría a usted.

* Python 2.6 en realidad es estable, la razón por la que no se declara como tal en Gentoo es que Gentoo confía en otros programas que dependen de Python y que aún no están actualizados para trabajar con 2.6. Nuevamente, este razonamiento probablemente no se aplica a usted.

Answer 2

Mi empresa está estandarizada en 2.5. Al igual que usted, no podemos hacer el cambio a 3.0 por un millón de razones, pero desearía que pudiéramos pasar a 2.6.

Haciendo la codificación día a día, revisaré la documentación y encontraré exactamente el módulo o la función que quiero, pero luego tendrá la pequeña anotación: Nuevo en la Versión 2.6

Yo diría que vaya con la versión más reciente, y si aparece una advertencia de depreciación (probablemente habrá muy pocas), entonces busque la mejor manera de hacerlo. En general, su código será mejor con 2.6.

Answer 3

Para mí, lo más importante para seguir con Python 2.5+ es porque admite oficialmente ctypes , que cambió muchos sistemas de complementos.

Aunque puede encontrar ctypes para trabajar con 2.3 / 2.4, no están empaquetados oficialmente.

Así que mi sugerencia sería 2.5.

Answer 4

Nos estamos quedando con 2.5.2 por ahora. Nuestra pila de tecnología se centra en Django (pero tenemos una docena de otros bits y bobs). Así que nos mantenemos cerca de lo que hacen.

Tuvimos que volver a docutils a 0.4 para que funcionara con epydoc 3.0.1. Hasta ahora, esto no ha sido un gran problema, pero puede, en algún momento, hacer que reconsideremos nuestro uso de epydoc.

La actualización 2.6 es parte de nuestro plan de desarrollo. Tenemos presupuesto, pero no tenemos un horario fijo en este momento.

La actualización 3.0, de manera similar, es algo que les recuerdo a la gente. Tenemos que presupuestarlo. No lo haremos este año a menos que Django salte a 3.0. Podríamos hacerlo el año que viene.

Answer 5

Creo que la mejor solución es renunciar a la esperanza de una uniformidad total, aunque tener un entorno común es algo por lo que luchar. Siempre se enfrentará a problemas de versión, por ejemplo, al actualizar a la siguiente mejor versión de intérprete.

Por lo tanto, en lugar de tratarlo en una base por problema, puede resolver este problema observando bien la administración de su versión.

En lugar de liberar la fuente, vaya a los binarios que dependen de la plataforma (además de la distribución de la fuente).

Entonces, lo que haces es que definas un número de CPU compatibles, por ejemplo: x86-32, x86-64, sparc

Entonces cuales sistemas operativos: Linux, Windows, Solaris, FreeBSD

Para cada sistema operativo, admite varias de sus versiones principales.

El siguiente paso es proporcionar binarios para todos ellos.

Sí, esto requerirá bastante inversión en infraestructura y la configuración de la creación automática desde sus repositorios (¿los tiene?).

Las ventajas son que sus usuarios solo tienen que 'instalar' una cosa y puede cambiar fácilmente las versiones o incluso las versiones de mezcla. En realidad, incluso puede usar diferentes lenguajes de programación con este enfoque sin afectar demasiado la administración de su versión.