Fim do suporte para python 2.7?

133

Existe uma data / prazo conhecido em que o python 2.7 não será mais suportado em favor do python 3?

python python-3.x python-2.7 python-2.x Stiivi
fonte
8
Uma pergunta justa, desde que não haja duplicado, eu não poderia encontrar nenhum.
precisa
2
Esta questão parece ser off-topic porque é sobre o suporte de uma versão de idioma
Bummi
1
A melhor visão que eu poderia encontrar é esta tabela: docs.python.org/devguide/#status-of-python-branches
Matth
No início de 2018, a data limite foi especificada mais de perto: agora é 1º de janeiro de 2020. Quando as distribuições com a alteração "python" para apontar para "python3" é uma questão mais aberta.
ESR
stackoverflow.com/a/58401685/5025009
seralouk 15/10

Respostas:

109

Em 13 de abril de 2014, em http://hg.python.org/peps/rev/76d43e52d978 (PEP 373, programação de lançamento do Python 2.7):

A data de término da vida útil (EOL, data do pôr-do-sol) do Python 2.7 foi alterada para cinco anos no futuro, para 2020. Essa decisão foi tomada para esclarecer o status do Python 2.7 e aliviar as preocupações dos usuários que ainda não podem migrar para o Python 3. Veja também PEP 466 .

Marco Mariani
fonte
23
@ Basic Exceto que não está cheio de vulnerabilidades.
Stian OK
5
@StianOK Ele tem seu quinhão: cvedetails.com/vulnerability-list/vendor_id-10210/…
Básico
14
@ Welll básico ... essa parte é muito pequena: 25 em todas as versões python (4% de código exec): cvedetails.com/product/18230/Python-Python.html?vendor_id=10210 vs php with 408 (27% code exec ): cvedetails.com/product/128/PHP-PHP.html?vendor_id=74 ou Java com 438 (3% de código executivo): cvedetails.com/product/19117/Oracle-JRE.html?vendor_id=93 ... Então, com "sua parte justa", você deve ter significado uma "parte notavelmente baixa". Além disso, todas, exceto três dessas vulnerabilidades, também estavam em uma versão 3.x e todas as versões atualizadas foram corrigidas.
precisa saber é
2
@ Básico Você tem uma sugestão melhor para uma linha de base de segurança?
dhj
2
@dhj Sim ... Não é Java! Ok, isso é injusto. Brincadeiras / brincadeiras à parte, a resposta honesta é não, não sei. Por isso fui com "quinhão". Não existe um idioma por aí que não possua vulnerabilidades conhecidas (e desconhecidas). Eu diria que, como regra geral, quanto mais amplamente usada uma linguagem é a vulnerabilidade mais conhecida, puramente em função do escrutínio, também conhecido como uso / recompensa da exploração. Não estou dizendo que o Python é pior do que outras línguas do ponto de vista da segurança, mas também não é melhor. A única resposta real é programar defensivamente e ter segurança em profundidade.
Basic
29

Em maio de 2010, a Palavra de Deus foi que as versões em nível de patch para o Python 2.7 provavelmente serão feitas por pelo menos 6 anos .

Então, talvez 2016, provavelmente mais tarde.

Edit: Adiado para 2020. Consulte a revisão do PEP 373, vinculada a outras respostas.

Frédéric Hamidi
fonte
2
Para qualquer pessoa que encontre essa resposta no futuro, conforme anunciado pelo próprio BDFL na PyCon 2014, a manutenção da 2.7 será estendida para 2020 agora.
Silas Ray
15

você deve ler isso com atenção (ref: https://news.ycombinator.com/item?id=7582300 ):

Existem muitos comentários aqui de pessoas que não estão na lista python-dev e realmente não entendem o que essa diferença realmente significa. Os desenvolvedores principais não precisam manter o 2.7 após 2015, e a maioria deles não estará envolvida. Essa parte não mudou. O que está acontecendo é que a Red Hat está se preparando para lançar um lançamento do RHEL 7, que o AFAIK depende de quanto você paga a eles por 13 anos. Portanto, eles precisam descobrir como se sustentar no 2.7 até 2027. Aqui é onde estou lendo nas entrelinhas. O RH tem todo o direito de usar o Python e manter seus patches de manutenção para si e para seus clientes (o Python não é copyleft). Mas, eles são caras legais e, portanto, talvez estejam dispostos a atualizar suas alterações pelo menos por um tempo, se ainda houver um projeto Python disposto a aceitá-las. Novamente, esta é a minha especulação baseada na discussão do ML, não o que o RH realmente disse que fará. Uma analogia pode ser feita com o Rails LTS, uma bifurcação comercial do Rails 2.x que o patio11 estava envolvido em [0]. Inevitavelmente, alguém vai dar suporte ao 2.7, e então vamos ver o que podemos fazer para evitar uma situação em que a única maneira de continuar executando o 2.7 seja assinando o RHEL. Enquanto isso, existem algumas grandes empresas que usam o 2.7 extensivamente no Windows (por exemplo, Enthought, Anaconda) e pensa-se que alguém provavelmente produza um instalador do Windows de vez em quando, assumindo que o Python.org ainda hospede um download. Então, realmente, o que está acontecendo aqui não é muito emocionante. Os comprometedores principais não estão fazendo nada diferente de deixar o projeto como planejado originalmente. O que está acontecendo é que eles deixarão as luzes acesas no repositório de controle de origem e no servidor FTP, para capturar a mão-de-obra livre de pessoas de grandes empresas que têm interesse em continuar suportando o 2.7. A alternativa é que RH e outros fornecedores criem garfos proprietários e caros do Python 2.7. Isso pode acabar acontecendo de qualquer maneira, mas levará mais tempo para o seu empregador perceber que você deve parar de contribuir com os patches se os binários ainda aparecerem no python.org e você não precisar pedir à TI para configurar o SCM e um rastreador de erros, etc. O que está acontecendo é que eles deixarão as luzes acesas no repositório de controle de origem e no servidor FTP, para capturar a mão-de-obra livre de pessoas de grandes empresas que têm interesse em continuar suportando o 2.7. A alternativa é que RH e outros fornecedores criem garfos proprietários e caros do Python 2.7. Isso pode acabar acontecendo de qualquer maneira, mas levará mais tempo para o seu empregador perceber que você deve parar de contribuir com os patches se os binários ainda aparecerem no python.org e você não precisar pedir à TI para configurar o SCM e um rastreador de erros, etc. O que está acontecendo é que eles deixarão as luzes acesas no repositório de controle de origem e no servidor FTP, para capturar a mão-de-obra livre de pessoas de grandes empresas que têm interesse em continuar suportando o 2.7. A alternativa é que RH e outros fornecedores criem garfos proprietários e caros do Python 2.7. Isso pode acabar acontecendo de qualquer maneira, mas levará mais tempo para o seu empregador perceber que você deve parar de contribuir com os patches se os binários ainda aparecerem no python.org e você não precisar pedir à TI para configurar o SCM e um rastreador de erros, etc.

Navid Rahimi
fonte
10

Este artigo diz: "Quando o 2.7 for lançado, a linha 2.x passará para cinco anos no modo somente correção de bugs."

Então, até onde eu vejo, o Python 2.7 foi o último lançamento de adição de recursos 2.x, e embora os erros encontrados sejam corrigidos (por algum tempo), os novos recursos só vão para os lançamentos 3.x.

Arseny
fonte
3
Esse artigo também afirma que o Python 3 introduz o Unicode, então eu aceitaria o que diz com um pouco de sal. Mas mude "cinco anos" para "pelo menos cinco anos" e está correto.
Lennart Regebro
7

Há também um relógio de contagem regressiva bastante ameaçador para a EOS em 2020.

npit
fonte
6

O PEP 373 (Programação de Liberação do Python 2.7) é a fonte oficial do tipo de informação solicitada.

Atualmente, ele diz "Datas planejadas para o lançamento futuro:"

  • 2.7.7 Pode 2014
  • 2.7.8 novembro de 2014
  • 2.7.9 Pode 2015
  • além dessa data, libera conforme necessário

Além disso, diz "A data de término da vida útil (EOL, data do pôr-do-sol) para Python 2.7 foi alterada para cinco anos no futuro, para 2020".

Editado em abril de 2014, de acordo com http://hg.python.org/peps/rev/76d43e52d978

Dr. Jan-Philip Gehrcke
fonte
que alivio! espero que o python 3 esteja morto até então ou renomeado para algo como morella para parar a confusão.
Lowtech
2
@lowtech - Eles podem ter migrado para o Python 4 até então (possivelmente introduzindo novas alterações incompatíveis com versões anteriores), mas não espero que 3 tenham morrido. Com base na rapidez com que o 3 vem crescendo em popularidade nos últimos anos, espero que a comunidade tenha mais pessoas usando 3 do que 2 até 2020. Ainda continuo segurando o Python 2, no entanto ... não há mudanças convincentes suficientes para fazer o risco de pular para 3. Eu importo muito do futuro .
ArtOfWarfare
6

O Python Developer's Guide lista o " Status das ramificações do Python " da versão 2.6 até a versão atual, incluindo seu status de suporte atual com datas de final de vida útil.

Atualmente suportado (bug + correções de segurança):

  • Python 3.8 (mestre atual / ramo de desenvolvimento)
  • Python 3.7
  • Python 3.6
  • Python 2.7 (até 01-01 2020)

Somente correções de segurança:

  • Python 3.5
  • Python 3.4
chrki
fonte
1

O Python 2.7 estará presente para sempre. Há muito código antigo que o utiliza e ninguém quer reescrever. Já existe uma bifurcação chamada Tauthon, mas podemos ver outras se esse prazo inútil se concretizar.

Máx.
fonte
2
Não é "inútil" para os produtos EOL, trata-se de alocação de recursos. Obviamente, como é de código aberto, estará disponível para sempre em sua forma atual. Mas não será mais suportado . Pelo menos pelos mantenedores oficiais. Não tenho muita certeza de que pergunta você está respondendo aqui.
deceze
O usuário perguntou por quanto tempo haverá suporte para o Python2.7. O usuário não perguntou sobre o suporte dos mantenedores oficiais. Com um projeto como esse, com tantas linhas de código disponíveis, na prática, haverá atualizações regulares, backports e bom suporte para o Python2 para sempre, por não mantenedores. (Eu me empolguei com minha frustração pessoal com toda essa coisa do Python3, daí o "inútil").
Max
Eu sinto que este comentário é relevante. Tauthon é idêntico ao Python 2.7 e parece que será suportado por um tempo. Portanto, vale a pena mencionar.
Phil
Fiz a experiência de que programadores mais jovens não entendem o poder e a eficiência advindos da garantia de compatibilidade com versões anteriores. Nunca entenderei a decisão de Guide van Rossum de causar danos, mais de dezenas de milhares de horas de vida desperdiçada, quebrando intencionalmente a compatibilidade, sem nenhum benefício (nem desempenho nem legibilidade).
Max
1
@Etragrammaton: por favor, explique por que não ser compatível é uma coisa boa. Por favor, explique qual seria a "falha fundamental". Trabalho com Python em tempo integral há mais de 15 anos e não vejo uma grande diferença relevante para mim. C permaneceu o mesmo por 40 anos e ainda é um idioma importante e não mudou muito. O Javascript melhorou extremamente ao longo dos anos e ainda é compatível com versões anteriores. O C ++ ainda é compatível com o C. O Windows 10 ainda pode executar os programas do Windows 3. Nossas CPUs ainda executam o código 8086 dos anos 70. Progredimos todos os dias, sem quebrar o apoio.
Max