Por que as pessoas hesitam em usar o Python 3?

221

O Python 3 foi lançado em dezembro de 2008. Muito tempo se passou desde então, mas ainda hoje muitos desenvolvedores hesitam em usar o Python 3. Mesmo estruturas populares como o Django ainda não são compatíveis com o Python 3, mas ainda dependem do Python 2.

Claro, o Python 3 tem algumas incompatibilidades com o Python 2 e algumas pessoas precisam confiar na compatibilidade com versões anteriores. Mas o Python 3 não existe há tempo suficiente para a maioria dos projetos alternar ou iniciar com o Python 3?

Ter duas versões concorrentes tem tantas desvantagens; dois ramos precisam ser mantidos, confusão para os alunos e assim por diante. Então, por que há tanta hesitação em toda a comunidade Python em mudar para o Python 3?

Ham Vocke
fonte
3
Existem realmente muitos projetos novos começando a usar o Python 2? Ou são apenas projetos há muito estabelecidos como o Django?
Carson63000
3
Você pode citar algumas das discussões / fontes?
Michael Easter
12
@ Michael Easter - Ele não precisa. Basta verificar a tag python no SO; muitas pessoas lá de cima são da opinião "aprender 2.x, 3.x ainda não está pronto".
Rook
5
Você ainda não viu o Python 3 Wall of Shame ?
detly
7
@detly, é agora chamar Python 3 Muralha da superpotência
freeforall tousez

Respostas:

249

Observe que não estou mais atualizando esta resposta. Tenho uma sessão de perguntas e respostas do Python 3 muito mais longa no meu site pessoal em http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html

Resposta anterior:

(Atualização de status, setembro de 2012)

Nós (ou seja, os desenvolvedores principais do Python) previmos quando o Python 3.0 foi lançado que levaria cerca de 5 anos para que o 3.x se tornasse a opção "padrão" para novos projetos na série 2.x. Essa previsão é a razão pela qual o período de manutenção planejada para a versão 2.7 é tão longo.

A versão original do Python 3.0 também apresentou alguns problemas críticos com baixo desempenho de IO que a tornaram efetivamente inutilizável para fins mais práticos, por isso faz mais sentido iniciar a linha do tempo a partir da versão do Python 3.1 no final de junho de 2009. (Aqueles Os problemas de desempenho de E / S também são a razão pela qual não há versões de manutenção 3.0.z: não há uma boa razão para alguém querer manter o 3.0 em vez de atualizar para o 3.1).

No momento da redação deste artigo (setembro de 2012), isso significa que estamos atualmente um pouco mais de três anos no processo de transição, e essa previsão ainda parece estar no caminho certo.

Enquanto as pessoas que digitam o código Python 3 são mordidas com mais frequência por alterações sintáticas como printse tornar uma função, isso na verdade não é um aborrecimento para a transferência de bibliotecas, porque a 2to3ferramenta de conversão automatizada lida com isso com bastante satisfação.

O maior problema na prática é na verdade semântico: o Python 3 não permite que você jogue rápido e livre com codificações de texto da mesma forma que o Python 2. Esse é o seu maior benefício em relação ao Python 2, mas também a maior barreira para a portabilidade: você precisa corrigir os problemas de manipulação do Unicode para que uma porta funcione corretamente (enquanto no 2.x, grande parte desse código produzia dados incorretos silenciosamente com entradas não ASCII, dando a impressão de funcionar, especialmente em ambientes onde dados não ASCII são incomuns).

Até a biblioteca padrão no Python 3.0 e 3.1 ainda apresentava problemas de manipulação de Unicode, dificultando a portabilidade de muitas bibliotecas (especialmente aquelas relacionadas a serviços da web).

O 3.2 abordou muitos desses problemas, fornecendo um alvo muito melhor para bibliotecas e frameworks como o Django. O 3.2 também trouxe a primeira versão de trabalho wsgiref(o principal padrão usado para comunicação entre servidores da Web e aplicativos da Web escritos em Python) para 3.x, que era um pré-requisito necessário para adoção no espaço da Web.

Dependências chave como NumPy e SciPy já foram portados, ferramentas de instalação e gerenciamento de dependência gosto zc.buildout, pipe virtualenvestão disponíveis para 3.x, o lançamento Pyramid 1.3 suporta Python 3.2, a próxima Django 1.5 versão inclui suporte experimental Python 3, ea 12,0 liberação de a estrutura de rede Twisted abandonou o suporte ao Python 2.5 para abrir o caminho para a criação de uma versão compatível com o Python 3.

Além do progresso nas bibliotecas e estruturas de compatibilidade do Python 3, a popular implementação do interpretador PyPy compilada pelo JIT está trabalhando ativamente no suporte ao Python 3.

As ferramentas para gerenciar o processo de migração também melhoraram significativamente. Além da 2to3ferramenta fornecida como parte do CPython (que agora é considerada mais adequada para conversões únicas de aplicativos que não precisam manter suporte para a série 2.x), há também o python-modernizeque usa a 2to3infraestrutura para direcionar o (grande) subconjunto comum do Python 2 e Python 3. Essa ferramenta cria uma única base de código que será executada no Python 2.6+ e no Python 3.2+ com a ajuda da sixbiblioteca de compatibilidade. A versão do Python 3.3 também elimina uma das principais causas de "ruído" ao migrar aplicativos existentes compatíveis com Unicode: o Python 3.3 mais uma vez suporta o prefixo 'u' para literais de string (na verdade, nãonada em Python 3 - é apenas sido restaurada para evitar inadvertidamente fazer a migração para o Python 3 mais difícil para os usuários que tinham distinguido já correctamente o seu texto e literais binários em Python 2).

Então, na verdade, estamos muito felizes com o andamento das coisas - ainda faltam quase dois anos para o prazo original e as mudanças estão ocorrendo muito bem em todo o ecossistema Python.

Como muitos projetos não selecionam adequadamente os metadados do Índice de Pacotes Python e alguns projetos com mantenedores menos ativos foram forçados a adicionar suporte ao Python 3, os scanners PyPI puramente automatizados ainda oferecem uma visão muito negativa do estado da biblioteca do Python 3 Apoio, suporte.

Uma alternativa preferida para obter informações sobre o nível de suporte do Python 3 no PyPI é http://py3ksupport.appspot.com/

Esta lista é curada pessoalmente por Brett Cannon (desenvolvedor de longa data do Python), responsável por metadados incorretos do projeto, suporte ao Python 3 que está nas ferramentas de controle de código-fonte, mas ainda não em um release oficial e nos projetos que têm garfos mais atualizados ou alternativas que suportam o Python 3. Em muitos casos, as bibliotecas que ainda não estão disponíveis no Python 3 não possuem dependências-chave e / ou a falta de suporte ao Python 3 em outros projetos diminui a demanda do usuário (por exemplo, uma vez que a estrutura principal do Django esteja disponível em As ferramentas relacionadas ao Python 3, como South e django-aipo, são mais propensas a adicionar suporte ao Python 3, e a disponibilidade do suporte ao Python 3 no Pyramid e no Django aumenta a probabilidade de o suporte ao Python 3 ser implementado em outras ferramentas, como gevent).

O site em http://getpython3.com/ inclui excelentes links para livros e outros recursos para o Python 3, identifica algumas bibliotecas e estruturas principais que já suportam o Python 3 e também fornece algumas informações sobre como os desenvolvedores podem procurar ajuda financeira do PSF ao portar projetos importantes para o Python 3.

Outro bom recurso é a página wiki da comunidade sobre fatores a serem considerados ao escolher uma versão do Python para um novo projeto: http://wiki.python.org/moin/Python2orPython3

ncoghlan
fonte
3
Atualizados com base no progresso nos últimos 18 meses (e observou explicitamente o fato de que 3.1 foi o primeiro lançamento verdadeira 3.x produção viável devido ao péssimo desempenho IO em 3.0)
ncoghlan
11
Até certo ponto (ou seja, sabíamos que era significativamente mais lento que o subsistema io na versão 2.6), mas o impacto na usabilidade geral foi muito pior do que imaginávamos (nossos benchmarks de IO melhoraram acentuadamente desde então, então não há chance de que algo assim seja enviado hoje)
ncoghlan 30/10
6
O prazo proposto não parece tão entusiasmado agora em 2015: |
Zetah 3/03
11
A maneira como eu vejo (e serei queimado na fogueira por alguns por isso) é que, na frente da codificação, o Py3 violou (e ainda o faz, como é o caso) o Zen do Python no ponto "o pragmatismo supera a pureza" : Py3 é puro para codificação. Py2 foi codificado-pragmático.
Jürgen A. Erhard
2
O Py3 ainda é pragmático em relação às codificações (caso contrário, não teríamos o surrogateescape), apenas encontramos muitos usuários * nix que não estão interessados ​​em ouvir sobre o funcionamento das interfaces do sistema operacional em plataformas como Windows, .NET e JVM ( incluindo Android). Escrevi mais sobre isso em developerblog.redhat.com/2014/09/09/… O principal impacto foi na frente "os erros não devem passar silenciosamente", pois mudamos os bugs dependentes de dados que produziam mojibake em erros de tipo estrutural reclamando sobre a mistura de dados binários e dados de texto.
Ncoghlan
48

Eu acredito que muita hesitação vem de duas coisas:

  • Se não estiver quebrado, não conserte
  • [Biblioteca XYZ] que exigimos não tem uma porta 3.0

Existem algumas diferenças na maneira como o idioma principal se comporta, descrito neste documento . Algo tão simples como alterar "print" de uma instrução para uma função, por exemplo, quebrará muitos códigos do Python 2.x - e isso é apenas o mais simples. Eles se livraram completamente das classes de estilo antigo no 3.0. Eles são, de fato, linguagens bem diferentes - portanto, portar código antigo não é tão simples quanto alguns podem supor.

TZHX
fonte
2
O problema da dependência-não-tem-uma porta também é recursivo. O que é necessário é que as bibliotecas amplamente usadas tenham poucas ou nenhuma dependência fora do stdlib to port, o que pode iniciar uma reação em cadeia.
Tony Meyer
10
Eu trocaria a ordem. Muitos de nós estão andando ao redor, esperando por um pacote específico para migrar a 3.
S.Lott
11
@ Tony - é por isso que acho que é ótimo para o 3.0 que o Numpy esteja agora disponível para ele. @ S.Lott - Eu acho que realmente depende se 3 oferece algo que você deseja. Para ser sincero, mudei recentemente de 2,5 para 2,7 - então não sou uma dessas pessoas que segue o "melhor e o mais recente".
TZHX 31/03
11
Portar códigos antigos com a ajuda de 2to3não é tão difícil quanto algumas pessoas temem.
Ncoghlan 31/03
5
Não ajuda que praticamente todos os sistemas operacionais que incorporam o Python à distribuição (OSX, Linux, etc) ainda estejam presos em alguma versão antiga do Python 2. Por que escrever no Python 3 quando ninguém pode usar seu código sem se preocupar com isso? com os internos do seu sistema operacional?
Ant
28

Não há motivos compulsivos para que as empresas existentes gastem tempo, dinheiro e esforço migrando para algo sem ter nenhuma alteração no conjunto de recursos existente. Quero dizer que a base de código da série Python 2 está em funcionamento há muito tempo, é estável, testada e possui todos os recursos atuais do produto. Por que alguém gastaria tempo, dinheiro e esforço apenas para mover o Python 3 apenas para migrar para ele.

Além da pós-migração, assegurando que não haja falhas de regressão e toda essa dor de cabeça é inevitável.

Para novos projetos, a política é clara e simples, tudo começa nos seguintes pontos:

  1. Alguma distro como o Ubuntu envia o Python 3 em sua instalação padrão?
  2. Qual é o ecossistema de bibliotecas do Python 3.
  3. Todas as estruturas e outros são compatíveis com o Python 3. etc etc.

É o seu processo habitual de 'escolher um novo idioma'. É aqui que entra o problema do ovo da galinha. Muitas pessoas não o estão usando porque poucas pessoas o estão usando. Em última análise, ninguém sente vontade de mudar para ele.

Quebrar a compatibilidade com versões anteriores nunca foi uma coisa boa; no final, você sempre encerra uma boa porcentagem de usuários.

kamaal
fonte
14

Na época em que o Python 2.0 foi lançado, o Python estava crescendo rapidamente em popularidade. Muitos usuários novos usaram naturalmente a versão mais recente, pois não tinham dependência das versões mais antigas. Com muitas pessoas adotando o 2.0 por padrão, houve muita pressão nos desenvolvedores de bibliotecas etc.

Quando o Python 3.0 foi lançado, já havia um grande número de usuários dependentes do Python 2.0, e o crescimento exponencial (mantendo um fator constante em relação aos usuários existentes) obviamente não podia ser sustentado indefinidamente.

Pessoalmente, os novos recursos dos dias 2 do Python pareciam muito mais atraentes do que os fornecidos pelo Python 3.

Eu achava que o Python 3 acabaria por assumir o controle de qualquer maneira, mas não tenho tanta certeza agora. Mas não é apenas o Python que tem esse problema. Afinal, quantas pessoas usam honestamente o Perl 6? Isso já dura um pouco mais do que o Python 3, IIRC.

Steve314
fonte
3
Inferno, ainda estou usando o Fortran77. :) E a maioria dos "recursos" reais do Python 3 foi transportada para o 2.6 e 2.7, sem tantos problemas de compatibilidade. A única coisa que o Python 3 realmente oferece é uma sintaxe "mais limpa".
TZHX 31/03
3
Comparar Python 3 e Perl 6 está errado. O Python 3 é um salto incremental do Python 2, enquanto o Perl 6 é um redesenho total. Perl 5 e Perl 6 são línguas irmãs e continuarão a coexistir por um longo tempo. Por outro lado, o Python 3 planeja substituir o Python 2, e não apenas coexistir. Isso é uma grande diferença.
#
11
Perl 6 ainda está em desenvolvimento. Sim, o Rakudo Perl é a implementação mais próxima da especificação Perl 6, mas ainda não implementa tudo. Simplesmente ainda não há implementação Perl 6 pronta para produção.
Htbaa 31/03
11
@Htbaa para muitas definições de integridade e prontidão. Perl 6 está completo e pronto para produção. O problema é que pode demorar um pouco para corresponder à especificação completa; também existem coisas semelhantes com outros idiomas. Por exemplo, o GCC, até recentemente, não correspondia realmente a toda a especificação C ++. O design e a implementação do idioma são um processo muito lento.
#
11
rakudo.org/node/75 A estrela de Rakudo foi lançada há muito tempo. Você precisa tentar.
#
11

Um grande obstáculo para mim, que eu acho que não pode ser abordado pela tradução automática, é a divisão inteira. Eu tenho códigos científicos que dependem de x / 2 dando x arredondado para baixo (quando x é um número inteiro).

O Python 3 não faria isso, mas daria uma resposta 0,5 (para x ímpar).
Não posso simplesmente substituir todos / no meu código por // porque às vezes faço divisão de flutuação e, portanto, quero o comportamento de flutuação.

Portanto, para eu portar para o python 3, terei que vasculhar dezenas de milhares de linhas de código, verificando cada / e verificando se consigo descobrir se deveria ser / ou //.

Sharky
fonte
7
A opção "-Q" (2.2 a 2.7) pode gerar avisos de divisão. Além disso, o fixdiv.py usa esses avisos para atualizar as expressões em seus scripts.
Eryk Sun
10

O Python 3 é bom para iniciar um novo projeto se todas as bibliotecas necessárias já estiverem portadas no Py3k.

Se isto não é uma opção, usando Python 2.7 é o melhor dos dois mundos: você tem mais cada biblioteca criada para Python 2.x e você pode gradualmente alterar o seu código para ser Py3k-compatível, para que a migração é fácil quando você decidir sobre isto. A lista de itens de sintaxe do Py3k que você já possui no 2.7 é bastante longa, mas não esqueça de importar __future__. Meus favoritos são Unicode por padrão e a divisão sempre produz um float.

9000
fonte
10

Do ponto de vista dos serviços da web: Nenhuma das principais estruturas de servidor nem da web suporta o Python3.

Atualização: Obviamente esse foi o caso no início de 2011, a partir de agora (final de 2013), a maioria das principais estruturas está trabalhando com o Python3. No entanto, alguns ainda não são compatíveis. Um exemplo significativo seria Twisted, onde ainda está em andamento .

vartec
fonte
BTW, o Django acabou de começar a dar suporte experimental ao Python3, na versão 1.5.
9000
11
O Django 1.6 agora suporta oficialmente o Python 3. O Flask também suporta.
Chhantyal 9/11
8

Não há razões convincentes para usar o P3K, a menos que você esteja fazendo um trabalho pesado do i18n. Nas minhas incursões, descobri que o difuso Unicode é uma barreira ao meu trabalho (ASCII) e aos geradores obrigatórios para entupir meu código.

Em alguns anos, 3 apresentarão um ambiente mais atraente, mas não hoje.

Paul Nathan
fonte
4

As distribuições não disponibilizam o Python3. Existem algumas distros adicionais que já fazem a transição do Python2. Mas as principais variantes do Linux, como Debian, Ubuntu etc., não. Essa é a principal razão para eu, como autor do aplicativo, não fazer isso também.

Embora eu tenha preparado a transição e até tente evitar as construções de sintaxe que foram incompatibilizadas , não posso testá-la adequadamente. Tudo se resume ao problema do ovo e da galinha.

mario
fonte
4
Isso pode ter sido verdade uma vez, mas "apt-get install python3" e "yum install python3" funcionaram por um longo tempo. Ferramentas como tox e serviços como o Shining Panda CI tornam fácil testar em várias versões do Python.
Ncoghlan
Agora, muitas dessas distribuições instalam python3 por padrão, ao contrário de muitas outras linguagens de programação.
Antti Haapala