¿Por qué la gente duda en usar Python 3?

Python 3 se lanzó en diciembre de 2008. Ha pasado mucho tiempo desde entonces, pero aún hoy muchos desarrolladores dudan en usar Python 3. Incluso los marcos populares como Django aún no son compatibles con Python 3, pero aún dependen de Python 2.

Claro, Python 3 tiene algunas incompatibilidades con Python 2 y algunas personas necesitan confiar en la compatibilidad con versiones anteriores. ¿Pero no ha existido Python 3 el tiempo suficiente para que la mayoría de los proyectos cambien o comiencen con Python 3?

Tener dos versiones de la competencia tiene tantos inconvenientes; deben mantenerse dos ramas, confusión para los alumnos, etc. Entonces, ¿por qué hay tanta duda en toda la comunidad de Python sobre cambiar a Python 3?

Tenga en cuenta que ya no estoy actualizando esta respuesta. Tengo un Python 3 Q & A mucho más largo en mi sitio personal en http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html

Respuesta anterior:

(Actualización de estado, septiembre de 2012)

Nosotros (es decir, los desarrolladores principales de Python) predijimos cuando se lanzó Python 3.0 que tomaría aproximadamente 5 años para que 3.x se convirtiera en la opción "predeterminada" para nuevos proyectos en la serie 2.x. Esa predicción es la razón por la cual el período de mantenimiento planificado para la versión 2.7 es tan largo.

La versión original de Python 3.0 también resultó tener algunos problemas críticos con un bajo rendimiento de E / S que lo hicieron efectivamente inutilizable para la mayoría de los propósitos prácticos, por lo que tiene más sentido comenzar la línea de tiempo desde el lanzamiento de Python 3.1 a fines de junio de 2009. (Esos Los problemas de rendimiento de IO también son la razón por la cual no hay versiones de mantenimiento 3.0.z: no hay una buena razón por la que alguien quiera quedarse con 3.0 sobre la actualización a 3.1).

Al momento de escribir (septiembre de 2012), eso significa que actualmente estamos un poco más de 3 años en el proceso de transición, y esa predicción todavía parece estar en camino.

Si bien las personas que escriben código Python 3 son mordidas con mayor frecuencia por cambios sintácticos como printconvertirse en una función, en realidad no es una molestia para el portado de la biblioteca porque la 2to3herramienta de conversión automática lo maneja con bastante felicidad.

El mayor problema en la práctica es en realidad semántico: Python 3 no te permite jugar rápido y suelto con codificaciones de texto como lo hace Python 2. Este es su mayor beneficio sobre Python 2, pero también la mayor barrera para la portabilidad: debe solucionar sus problemas de manejo de Unicode para que un puerto funcione correctamente (mientras que en 2.x, gran parte de ese código silenciosamente produjo datos incorrectos con entradas no ASCII, dando la impresión de funcionar, especialmente en entornos donde los datos no ASCII son poco comunes).

Incluso la biblioteca estándar en Python 3.0 y 3.1 todavía tenía problemas de manejo de Unicode, lo que dificultaba el puerto de muchas bibliotecas (especialmente las relacionadas con los servicios web).

3.2 abordó muchos de esos problemas, proporcionando un objetivo mucho mejor para bibliotecas y marcos como Django. 3.2 también trajo la primera versión de trabajo wsgiref(el estándar principal utilizado para la comunicación entre servidores web y aplicaciones web escritas en Python) para 3.x, que era un requisito previo necesario para su adopción en el espacio web.

Las dependencias clave como NumPy y SciPy ahora se han portado, las herramientas de instalación y administración de dependencias como zc.buildout, pipy virtualenvestán disponibles para 3.x, la versión Pyramid 1.3 es compatible con Python 3.2, la próxima versión Django 1.5 incluye soporte experimental para Python 3 y la versión 12.0 de Twisted Network Framework dejó de admitir Python 2.5 para allanar el camino para crear una versión compatible con Python 3.

Además del progreso en las bibliotecas y marcos de compatibilidad de Python 3, la popular implementación del intérprete de PyPy compilado por JIT está trabajando activamente en el soporte de Python 3.

Las herramientas para gestionar el proceso de migración también han mejorado notablemente. Además de la 2to3herramienta proporcionada como parte de CPython (que ahora se considera más adecuada para las conversiones de aplicaciones únicas que no necesitan mantener el soporte para la serie 2.x), también existe python-modernize, que utiliza la 2to3infraestructura para apuntar El subconjunto común (grande) de Python 2 y Python 3. Esta herramienta crea una base de código único que se ejecutará tanto en Python 2.6+ como en Python 3.2+ con la ayuda de la sixbiblioteca de compatibilidad. La versión Python 3.3 también elimina una de las principales causas de "ruido" al migrar las aplicaciones compatibles con Unicode: Python 3.3 una vez más admite el prefijo 'u' para literales de cadena (en realidad no lo hacecualquier cosa en Python 3: se ha restaurado para evitar que la migración a Python 3 sea inadvertidamente más difícil para los usuarios que ya habían distinguido correctamente sus textos y literales binarios en Python 2).

Por lo tanto, estamos bastante contentos con la forma en que progresan las cosas: todavía quedan casi 2 años en nuestro marco de tiempo original, y los cambios se están extendiendo muy bien en todo el ecosistema de Python.

Dado que muchos proyectos no conservan adecuadamente los metadatos de su índice de paquete Python, y algunos proyectos con mantenedores menos activos se han bifurcado para agregar compatibilidad con Python 3, los escáneres PyPI puramente automáticos aún ofrecen una visión demasiado negativa del estado de la biblioteca de Python 3 apoyo.

Una alternativa preferida para obtener información sobre el nivel de soporte de Python 3 en PyPI es http://py3ksupport.appspot.com/

Esta lista está curada personalmente por Brett Cannon (un desarrollador principal de Python desde hace mucho tiempo) para dar cuenta de metadatos de proyecto incorrectos, soporte de Python 3 que está en herramientas de control de fuente pero aún no en un lanzamiento oficial, y proyectos que tienen tenedores más actualizados o alternativas que admiten Python 3. En muchos casos, las bibliotecas que aún no están disponibles en Python 3 carecen de dependencias clave y / o la falta de soporte de Python 3 en otros proyectos disminuye la demanda del usuario (por ejemplo, una vez que el marco Django está disponible en Python 3, las herramientas relacionadas como South y django-celery tienen más probabilidades de agregar soporte para Python 3, y la disponibilidad de soporte para Python 3 en Pyramid y Django hace que sea más probable que el soporte para Python 3 se implemente en otras herramientas como gevent).

El sitio en http://getpython3.com/ incluye algunos enlaces excelentes a libros y otros recursos para Python 3, identifica algunas bibliotecas y marcos clave que ya son compatibles con Python 3, y también proporciona información sobre cómo los desarrolladores pueden buscar ayuda financiera del PSF en portar proyectos clave a Python 3.

Otro buen recurso es la página wiki de la comunidad sobre los factores a considerar al elegir una versión de Python para un nuevo proyecto: http://wiki.python.org/moin/Python2orPython3

Creo que muchas de las dudas provienen de dos cosas:

• Si no está roto, no lo arregles
• [Biblioteca XYZ] que requerimos no tiene un puerto 3.0

Existen bastantes diferencias en la forma en que se comporta el lenguaje central, descritas en este documento . Algo tan simple como cambiar "imprimir" de una declaración a una función, por ejemplo, romperá una gran cantidad de código Python 2.x, y eso es solo lo más simple. Se deshicieron de las clases de estilo antiguo por completo en 3.0. De hecho, son idiomas bastante diferentes, por lo que portar código antiguo no es tan simple como algunos podrían suponer.

No hay razones compulsivas para que las empresas existentes gasten tiempo, dinero y esfuerzo migrando a algo sin tener cambios en el conjunto de características existentes. Quiero decir que la base de código en la serie Python 2 ha estado funcionando en los negocios durante mucho tiempo, es estable, probado y tiene todas las características actuales del producto. ¿Por qué alguien gastaría tiempo, dinero y esfuerzo solo para mover Python 3 solo por migrar a él?

Además de la migración posterior, se garantiza que no haya fallas de regresión y que todo ese dolor de cabeza sea inevitable.

Para nuevos proyectos, la política es simple y simple, todo comienza en los siguientes puntos:

1. ¿Alguna distribución como Ubuntu incluye Python 3 en su instalación predeterminada?
2. ¿Cuál es el ecosistema de la biblioteca para Python 3?
3. ¿Todos los frameworks y otros son compatibles con Python 3. etc. etc.

Es su proceso habitual de 'elegir un nuevo idioma'. Aquí es donde entra el problema del huevo de gallina. No muchas personas lo están usando porque no muchas personas lo están usando. En última instancia, nadie tiene ganas de moverse en absoluto.

Romper la compatibilidad con versiones anteriores nunca ha sido algo bueno, al final siempre terminas con un buen porcentaje de usuarios.

Cuando se lanzó Python 2.0, Python estaba creciendo rápidamente en popularidad. Hubo muchos usuarios nuevos que usaron naturalmente la última versión, ya que no tenían dependencias de las versiones anteriores. Con mucha gente adoptando 2.0 por defecto, había mucha presión sobre los desarrolladores de bibliotecas, etc.

Para cuando se lanzó Python 3.0, ya había una gran cantidad de usuarios que dependían de Python 2.0, y el crecimiento exponencial (manteniendo un factor constante en relación con los usuarios existentes) obviamente no se puede mantener indefinidamente.

Personalmente, las nuevas características en los días de Python 2 parecían mucho más convincentes que las proporcionadas por Python 3.

Solía ​​pensar que Python 3 eventualmente se haría cargo de todos modos, pero ahora no estoy tan seguro. Pero no solo Python tiene este problema. Después de todo, ¿cuántas personas usan honestamente Perl 6? Eso ha estado bastante más tiempo que Python 3, IIRC.

Un gran obstáculo para mí, que no creo que pueda abordarse mediante traducción automática, es la división de enteros. Tengo códigos científicos que se basan en x / 2 dando x redondeado hacia abajo (cuando x es entero).

Python 3 no haría eso, pero daría una respuesta de .5 (para x impar).
No puedo reemplazar todo / en mi código con // porque a veces hago división flotante, y por lo tanto quiero el comportamiento flotante.

Entonces, para que pueda portar a Python 3, tendré que rastrear a través de decenas de miles de líneas de código, verificar cada / y ver si puedo averiguar si debería ser / o //.

Python 3 es bueno para comenzar un nuevo proyecto si todas las bibliotecas que necesita ya están portadas a Py3k.

Si esto no es una opción, usando Python 2.7 es lo mejor de ambos mundos: usted tiene la mayoría de cada biblioteca creada para Python 2.x y se puede modificar gradualmente su código para ser Py3k-compatibles, por lo que la migración es fácil cuando se decide por eso. La lista de ventajas de sintaxis de Py3k que ya tienes en 2.7 es bastante larga, solo no olvides importar desde __future__. Mis favoritos son Unicode por defecto y la división siempre produce un flotante.

Desde la perspectiva de los servicios web: ninguno de los principales marcos de servidores ni los marcos web admiten Python3.

Actualización: Obviamente ese fue el caso a principios de 2011, a partir de ahora (finales de 2013), la mayoría de los marcos principales están trabajando con Python3. Sin embargo, algunos todavía no son compatibles. Un ejemplo significativo sería Twisted, donde todavía está en progreso .

No he visto razones convincentes para usar P3K a menos que esté haciendo un trabajo pesado. En mis incursiones, descubrí que el penetrante Unicode es una barrera para mi trabajo (ASCII) y los generadores obligatorios para obstruir mi código.

En unos años, 3 presentará un entorno más atractivo, pero no hoy.

Las distribuciones no hacen que Python3 esté disponible. Hay algunas distribuciones marginales que ya hacen la transición de Python2. Pero las variantes principales de Linux como Debian, Ubuntu, etc., no. Esa es la razón principal para que yo, como autor de la aplicación, tampoco lo haga.

Aunque preparé la transición e incluso trato de evitar las construcciones de sintaxis que han sido incompatibilizadas , no puedo probarlo adecuadamente. Se reduce al problema del huevo y la gallina realmente.