Por que as pessoas hesitam em usar o Python 3?

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?

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

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.

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.

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.

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

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.

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 .

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.

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.