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

221

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?

Jamón Vocke
fuente
3
¿Realmente hay tantos proyectos nuevos que comienzan a usar Python 2? ¿O son solo proyectos de larga data como Django?
Carson63000
3
¿Puedes citar algunas de las discusiones / fuentes?
Michael Easter
12
@Michael Easter - No tiene que hacerlo. Simplemente verifique la etiqueta de python en SO; mucha gente allá arriba opina "aprende 2.x, 3.x aún no está listo".
Torre
55
¿No has visto el Python 3 Wall of Shame ?
detly
77
@detly, ahora se llama Python 3 Wall of Superpower
freeforall tousez

Respuestas:

249

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

ncoghlan
fuente
3
Actualizado según el progreso de los últimos 18 meses (y señaló explícitamente el hecho de que 3.1 fue la primera versión 3.x viable de producción real debido al rendimiento abismal de IO en 3.0)
ncoghlan
1
Hasta cierto punto (es decir, sabíamos que era significativamente más lento que el subsistema io en 2.6), pero el impacto en la usabilidad general fue mucho peor de lo que esperábamos (nuestros puntos de referencia IO han mejorado notablemente desde entonces, por lo que no hay posibilidad de que algo así sea enviado hoy)
ncoghlan
66
El plazo propuesto no parece tan entusiasta ahora en 2015: |
zetah
1
La forma en que lo veo (y algunos me quemarán en la hoguera por esto) es que en el frente de la codificación, Py3 violó (y aún lo hace, como sucede) el Zen de Python en el punto "el pragmatismo supera la pureza" : Py3 es pura codificación. Py2 estaba codificando-pragmático.
Jürgen A. Erhard
2
Py3 sigue siendo pragmático acerca de las codificaciones (de lo contrario, no tendríamos un paisaje sustituto), nos encontramos con muchos usuarios de * nix que no están interesados ​​en saber cómo funcionan las interfaces del sistema operativo en plataformas como Windows, .NET y JVM ( incluido Android). He escrito más sobre eso en developerblog.redhat.com/2014/09/09/... El impacto principal ha sido en el frente "los errores no deben pasar en silencio", ya que cambiamos los errores dependientes de los datos que produjeron mojibake en errores de tipo estructural quejándose de mezclar datos binarios y datos de texto.
ncoghlan
48

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.

TZHX
fuente
2
El problema de dependencia-no-tiene-un puerto también es recursivo. Lo que se necesita es para bibliotecas ampliamente utilizadas que tengan pocas o ninguna dependencia fuera de stdlib to port, que luego pueden iniciar una reacción en cadena.
Tony Meyer
10
Cambiaría el orden. Muchos de nosotros estamos dando vueltas, esperando que un paquete en particular migre a 3.
S.Lott
1
@ Tony - por eso creo que es una gran bendición para 3.0 que Numpy ahora esté disponible para ello. @ S.Lott: supongo que realmente depende de si 3 ofrece algo que desee. Para ser honesto, solo recientemente pasé de 2.5 a 2.7, por lo que no soy realmente una de esas personas que sigue a los "últimos y mejores".
TZHX
1
Sin embargo, portar código antiguo con la ayuda de 2to3no es tan difícil como algunas personas temen.
ncoghlan
55
No ayuda que casi todos los sistemas operativos que agrupan Python en la distribución (OSX, Linux, etc.) todavía estén atascados en alguna versión antigua de Python 2. ¿Por qué escribir para Python 3 cuando nadie puede usar su código sin molestar? con lo interno de su sistema operativo?
Ant
28

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.

kamaal
fuente
14

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.

Steve314
fuente
3
Demonios, todavía estoy usando Fortran77. :) Y la mayoría de las "características" reales de Python 3 han sido respaldadas en 2.6 y 2.7, sin tantos problemas de compatibilidad. Lo único que realmente ofrece Python 3 es una sintaxis "más limpia".
TZHX
3
Comparar Python 3 y Perl 6 está mal. Python 3 es un salto incremental de Python 2 mientras que Perl 6 es un rediseño total desde cero. Perl 5 y Perl 6 son lenguas hermanas y continuarán coexistiendo durante mucho tiempo. Por otro lado, Python 3 planea reemplazar Python 2, no solo coexistir. Esta es una gran diferencia.
kamaal
1
Perl 6 todavía está en desarrollo. Sí, Rakudo Perl es la implementación más cercana a la especificación Perl 6 pero aún no implementa todo. Simplemente no hay implementación de Perl 6 lista para producción todavía.
Htbaa
1
@Htbaa para muchas definiciones de integridad y preparación. Perl 6 está completo y listo para la producción. La cuestión es que puede llevar un tiempo hacer coincidir la especificación completa, también hay cosas similares con otros idiomas. Por ejemplo, GCC incluso hasta hace poco no coincidía realmente con toda la especificación de C ++. El diseño y la implementación del lenguaje es un proceso muy lento.
kamaal
1
rakudo.org/node/75 Rakudo star fue lanzado hace mucho tiempo. Necesitas probarlo.
kamaal 31/03/11
11

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 //.

Sharky
fuente
77
La opción "-Q" (2.2 a 2.7) puede generar advertencias para la división. Además, fixdiv.py utiliza estas advertencias para actualizar las expresiones en sus scripts.
Eryk dom
10

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.

9000
fuente
10

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 .

vartec
fuente
Por cierto, Django acaba de comenzar a soportar experimentalmente Python3, en v 1.5.
9000
1
Django 1.6 ahora admite oficialmente Python 3. Flask también lo admite.
chhantyal el
8

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.

Paul Nathan
fuente
4

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.

mario
fuente
44
Esto puede haber sido cierto una vez, pero "apt-get install python3" y "yum install python3" han funcionado durante mucho tiempo. Herramientas como tox y servicios como Shining Panda CI hacen que sea sencillo realizar pruebas en múltiples versiones de Python.
ncoghlan
Ahora, muchas de estas distribuciones instalan python3 por defecto, a diferencia de muchos otros lenguajes de programación.
Antti Haapala