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

Question

En nuestro grupo, principalmente hacemos arquitectura de motores de búsqueda y trabajo de integración de contenido y la mayoría de esa base de código está en Python. Todas nuestras herramientas de compilación y las dependencias de los módulos de Python están en control de fuente para que puedan ser desprotegidos y el entorno cargado para su uso independientemente de os/plataforma, un poco similar al enfoque que usa virtualenv.

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. Con los años, esto ha causado más y más problemas a medida que las nuevas herramientas y bibliotecas necesitan versiones más nuevas de Python desde que salió el 2.3 en ~ 2004.

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

Python 3.0 no es una opción (por ahora) ya que tendríamos que migrar gran parte de nuestro código base para hacer que nuestras herramientas de compilación e integración vuelvan a funcionar correctamente.

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 genere varias advertencias de depreciación. Otra herramienta que nos interesa para administrar los nodos del clúster en la nube EC2, Supervisor ni siquiera funciona correctamente con Python 2.6.

Ahora me pregunto si deberíamos estandarizar en 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 resolver 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 simplemente debido a las advertencias de obsolescencia; esos desaparecerán con el tiempo. (Puede usar la opción -W ignore en 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, esa sería una razón legítima para quedarse con 2.5. Python 2.5 tiene un amplio uso ahora y probablemente se prolongue durante mucho tiempo (¡considera cuánto tiempo ha durado 2.3!), Por lo que incluso si utilizas 2.5, no te verás obligado a actualizar por un tiempo.

Utilizo Python 2.5 para todos mis trabajos 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 que Python 2.6 es "estable" *, cambiaré a eso. Por supuesto, este razonamiento no necesariamente se aplica a usted.

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

Answer 2

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

Aunque puede encontrar ctypes para trabajar con 2.3/2.4, oficialmente no se incluyen.

Así que mi sugerencia sería 2.5.

Answer 3

Mi empresa está estandarizada en 2.5. Al igual que usted, no podemos cambiar a 3.0 por un millón de razones, pero me gustaría mucho poder avanzar hasta 2.6.

Haciendo codificación día a día voy a estar mirando a través de la documentación y voy a encontrar exactamente el módulo o función que quiero, pero entonces va a tener la poca anotación: nuevo en la versión 2.6

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

Answer 4

Nos estamos quedando con 2.5.2 por ahora. Nuestra tecnología se centra en Django (pero tenemos una docena de otras cosas). Nos mantenemos cerca de lo que hacen.

Tuvimos que volver a docutils a 0.4 para que funcione con epydoc 3.0.1. Hasta ahora, este no ha sido un gran problema, pero puede, en algún momento, hacernos reconsiderar nuestro uso de epydoc.

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

La actualización 3.0, del mismo modo, 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 próximo año.

Answer 5

Creo que la mejor solución es perder la esperanza en la uniformidad total, aunque tener un entorno común es algo que debemos esforzarnos. Siempre se verá enfrentado a problemas de versión, por ejemplo al actualizar a la siguiente mejor versión de intérprete.

Por lo tanto, en lugar de tratar con una base por problema, puede resolver este problema eche un vistazo a su administración de versiones.

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

Así que lo que hace es que se define un número de CPU con el apoyo de, por ejemplo: x86-32, x86-64, SPARC

Entonces qué sistemas operativos: Linux, Windows, Solaris, FreeBSD

Para cada sistema operativo admite varias de sus versiones principales.

El siguiente paso es que proporciones binarios para todos ellos.

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

La ventaja es que sus usuarios solo tienen que instalar "uno" y puede cambiar fácilmente versiones o incluso mezclar versiones. De hecho, incluso puedes usar diferentes lenguajes de programación con este enfoque sin afectar demasiado tu gestión de lanzamientos.