¿Fin del soporte para Python 2.7?

133

¿Existe una fecha / marco de tiempo conocido cuando Python 2.7 ya no será compatible a favor de Python 3?

python python-3.x python-2.7 python-2.x Stiivi
fuente
8
Una pregunta justa, siempre y cuando no haya duplicados, no podría encontrar ninguno.
Matt Joiner el
2
Esta pregunta parece estar fuera de tema porque trata sobre el soporte de una versión de idioma
bummi
1
La mejor visión general que pude encontrar es esta tabla: docs.python.org/devguide/#status-of-python-branches
Matth
A principios de 2018, la fecha límite se ha especificado más de cerca: ahora es el 1 de enero de 2020. Cuando las distribuciones con cambio "python" apuntan a "python3" es una pregunta más abierta.
ESR
stackoverflow.com/a/58401685/5025009
seralouk

Respuestas:

109

A partir del 13 de abril de 2014, de http://hg.python.org/peps/rev/76d43e52d978 (PEP 373, Programa de lanzamiento de Python 2.7):

La fecha de finalización de la vida útil (EOL, fecha de caducidad) para Python 2.7 se ha movido cinco años en el futuro, hasta 2020. Esta decisión se tomó para aclarar el estado de Python 2.7 y aliviar las preocupaciones de aquellos usuarios que aún no pueden migrar a Python 3 Ver también PEP 466 .

Marco Mariani
fuente
23
@Basic Excepto que no está lleno de vulnerabilidades.
Stian OK
55
@StianOK Tiene su parte justa: cvedetails.com/vulnerability-list/vendor_id-10210/…
Básico
14
@Basic welll ... esa participación es bastante escasa: 25 en todas las versiones de Python (4% de código ejecutable ): cvedetails.com/product/18230/Python-Python.html?vendor_id=10210 vs php con 408 (27% de código exec) ): cvedetails.com/product/128/PHP-PHP.html?vendor_id=74 o Java con 438 (3% código exec): cvedetails.com/product/19117/Oracle-JRE.html?vendor_id=93 ... Entonces, por "su parte justa" debe haber significado una "parte notablemente baja". Además, todas menos 3 de esas vulnerabilidades también estaban en vulnerabilidades en una versión 3.xy todas las versiones actualizadas son reparadas.
dhj
2
@Basic ¿Tiene una mejor sugerencia para una línea de base de seguridad?
dhj
2
@dhj Sí ... ¡No Java! Ok, eso es injusto. Bromas / frivolidad a un lado, la respuesta honesta es no, no lo hago. Es por eso que fui con "parte justa". No existe un lenguaje que no tenga vulnerabilidades conocidas (y desconocidas). Yo diría que, como regla general, cuanto más se usa un lenguaje entre nosotros, las vulnerabilidades más conocidas existen, simplemente en función del escrutinio, también conocido como uso / recompensa de la explotación. No digo que Python sea peor que otros idiomas desde el punto de vista de la seguridad, pero tampoco es mejor. La única respuesta real es programar a la defensiva y tener seguridad en profundidad.
Básico
15

debe leer esto detenidamente (ref: https://news.ycombinator.com/item?id=7582300 ):

Aquí hay muchos comentarios de personas que no están en la lista python-dev y que realmente no entienden lo que realmente significa esta diferencia. Los desarrolladores principales no están obligados a mantener 2.7 después de 2015, y la mayoría de ellos no participarán en él. Esa parte no ha cambiado. Lo que está sucediendo es que Red Hat se está preparando para cortar un lanzamiento de RHEL 7, que AFAIK dependiendo de cuánto les pague, lo apoyan durante 13 años. Por lo tanto, necesitarán descubrir cómo soportar 2.7 por lo menos hasta 2027. Aquí es donde estoy leyendo entre líneas. RH está dentro de su derecho a bifurcar Python y mantener sus parches de mantenimiento para ellos y sus clientes (Python no tiene copyleft). Pero, son buenos tipos y, por lo tanto, tal vez estén dispuestos a actualizar sus cambios al menos por un tiempo si todavía hay un proyecto de Python dispuesto a aceptarlos. Nuevamente, esta es mi especulación basada en la discusión de LD, no en lo que RH realmente ha dicho que harán. Se puede hacer una analogía con Rails LTS, una bifurcación comercial de Rails 2.x en la que patio11 estuvo involucrado [0]. Inevitablemente, alguien va a intervenir para admitir 2.7, así que veamos qué podemos hacer para evitar una situación en la que la única forma de seguir ejecutando 2.7 es suscribirse a RHEL. Mientras tanto, hay algunas grandes empresas que usan 2.7 ampliamente en Windows (por ejemplo, Enthought, Anaconda) y se piensa que probablemente se pueda encontrar a alguien que produzca un instalador de Windows de vez en cuando, suponiendo que Python.org aún aloje una descarga. Entonces, realmente lo que está sucediendo aquí no es muy emocionante. Los encargados centrales no están haciendo nada diferente a dejar el proyecto como se planeó originalmente. Lo que está sucediendo es que dejarán las luces encendidas en el repositorio de control de fuente y en el servidor FTP, a fin de capturar la mano de obra gratuita de las personas en grandes empresas que tienen interés en continuar brindando asistencia 2.7. La alternativa es que RH y otros proveedores crean tenedores caros y propietarios de Python 2.7. Eso puede terminar sucediendo de todos modos, pero le tomará más tiempo a su empleador darse cuenta de que debe dejar de contribuir con sus parches si aún aparecen binarios en python.org y no tiene que pedirle a TI que configure SCM y un rastreador de errores, etc. Lo que está sucediendo es que dejarán las luces encendidas en el repositorio de control de fuente y en el servidor FTP, a fin de capturar la mano de obra gratuita de las personas en grandes empresas que tienen interés en continuar brindando asistencia 2.7. La alternativa es que RH y otros proveedores crean tenedores caros y propietarios de Python 2.7. Eso puede terminar sucediendo de todos modos, pero le tomará más tiempo a su empleador darse cuenta de que debe dejar de contribuir con sus parches si aún aparecen binarios en python.org y no tiene que pedirle a TI que configure SCM y un rastreador de errores, etc. Lo que está sucediendo es que dejarán las luces encendidas en el repositorio de control de fuente y en el servidor FTP, a fin de capturar la mano de obra gratuita de las personas en grandes empresas que tienen interés en continuar brindando asistencia 2.7. La alternativa es que RH y otros proveedores crean tenedores caros y propietarios de Python 2.7. Eso puede terminar sucediendo de todos modos, pero le tomará más tiempo a su empleador darse cuenta de que debe dejar de contribuir con sus parches si aún aparecen binarios en python.org y no tiene que pedirle a TI que configure SCM y un rastreador de errores, etc.

Navid Rahimi
fuente
10

Este artículo dice: "Cuando se publique 2.7, la línea 2.x pasará a cinco años de un modo de solo corrección de errores".

Por lo tanto, por lo que veo, Python 2.7 fue la última versión de adición de características 2.x, y aunque los errores encontrados se solucionarán (por algún tiempo), las nuevas características solo irán a las versiones 3.x.

Arsenio
fuente
3
Ese artículo también afirma que Python 3 introduce Unicode, por lo que tomaría lo que diga con un grano de sal. Pero cambie "cinco años" a "al menos cinco años" y es correcto.
Lennart Regebro
6

PEP 373 (Programa de lanzamiento de Python 2.7) es la fuente oficial del tipo de información que solicitó.

Actualmente dice "Planeadas futuras fechas de lanzamiento:"

  • 2.7.7 de mayo de 2014
  • 2.7.8 de noviembre de 2014
  • 2.7.9 de mayo de 2015
  • más allá de esta fecha, lanzamientos según sea necesario

Además, dice "La fecha de finalización de la vida útil (EOL, fecha de caducidad) para Python 2.7 se ha trasladado cinco años en el futuro, a 2020".

Editado en abril de 2014, de acuerdo con http://hg.python.org/peps/rev/76d43e52d978

Dr. Jan-Philip Gehrcke
fuente
¡qué alivio! Esperemos que Python 3 esté muerto para entonces o renombrado en algo como Morella para detener la confusión.
Lowtech
2
@lowtech: es posible que hayan pasado a Python 4 para entonces (posiblemente introduciendo nuevos cambios incompatibles con versiones anteriores), pero no espero que 3 se hayan extinguido. Según la rapidez con la que 3 ha ido aumentando en popularidad en los últimos años, espero que la comunidad tenga más personas usando 3 que 2 para 2020. Todavía me estoy aferrando a Python 2, aunque ... no hay suficientes cambios convincentes para hacer Sin embargo, el riesgo de saltar a 3. Importo mucho desde el futuro .
ArtOfWarfare
6

La Guía del desarrollador de Python enumera el " Estado de las ramas de Python " desde la versión 2.6 hasta la versión actual, incluido su estado de soporte actual con las fechas de finalización de la vida útil.

Actualmente compatible (error + correcciones de seguridad):

  • Python 3.8 (maestro actual / rama de desarrollo)
  • Python 3.7
  • Python 3.6
  • Python 2.7 (hasta 2020-01-01)

Solo soluciones de seguridad:

  • Python 3.5
  • Python 3.4
chrki
fuente
1

Python 2.7 estará presente para siempre. Hay demasiado código antiguo que lo usa que nadie quiere reescribir. Ya hay un tenedor llamado Tauthon, pero podemos ver otros si este plazo inútil se vuelve real.

Max
fuente
2
No es "inútil" para los productos EOL, se trata de la asignación de recursos. Por supuesto, dado que es de código abierto, existirá para siempre en su forma actual. Pero ya no será compatible . Al menos por los mantenedores oficiales. No estoy realmente seguro de qué pregunta estás respondiendo aquí.
deceze
El usuario preguntó cuánto tiempo habrá soporte para Python2.7. El usuario no preguntó sobre el soporte de los mantenedores oficiales. Con un proyecto como este, con tantas líneas de código por ahí, en la práctica, habrá actualizaciones periódicas, backports y un buen soporte para Python2 para siempre, por parte de personas que no sean de mantenimiento. (Me dejé llevar por mi frustración personal sobre todo esto de Python3, de ahí lo "inútil").
Max
Siento que este comentario es relevante. Tauthon es idéntico a Python 2.7 y parece que será compatible por un tiempo. Por lo tanto, vale la pena mencionar.
Phil
He tenido la experiencia de que los programadores más jóvenes no entienden el poder y la eficiencia que conlleva garantizar la compatibilidad con versiones anteriores. Nunca entenderé la decisión de Guide van Rossum de causar daño, más de decenas de miles de horas de vida desperdiciada, al romper intencionalmente la compatibilidad sin ningún beneficio (ni rendimiento ni legibilidad).
Max
1
@Tetragrammaton: explique por qué no ser compatible es algo bueno. Por favor explique cuál sería la "falla fundamental". He trabajado con Python a tiempo completo durante 15 años y no puedo ver una diferencia importante que sea relevante para mí. C se mantuvo igual durante 40 años y sigue siendo un idioma importante y no ha cambiado mucho. Javascript mejoró extremadamente con los años y todavía es compatible con versiones anteriores. C ++ sigue siendo compatible con versiones anteriores de C. Windows 10 todavía puede ejecutar programas de Windows 3. Nuestras CPU aún ejecutan el código 8086 de los años 70. Progresamos todos los días, sin romper el apoyo.
Max