O Python 3.0 (vulgo Python 3000) foi finalmente liberado há 3 meses atrás (3 de Dezembro de 2008). Faz quase 9 anos desde que Guido van Rossum, o 'autor' da linguagem, teve a visão desta nova e revolucionária versão do Python. O Python 3.0 quebra a compatibilidade retroativa com as versões anteriores da linguagem.
Em um post de 2007, Guido escreveu sobre como Python 3.0 foi concebido:
Por um bom tempo não havia muito mais do que uma lista de arrependimentos e defeitos estruturais que eram impossiveis de corrigir sem quebrar a compatibilidade retroativa. A idéia era que Python 3000 seria o primeiro release do Python a desistir desta compatibilidade em favor de tornar-se uma linguagem melhor e evoluir.
Em uma entrevista, Guido descreveu o que aconteceu depois:
Eu comecei com um esforço atual para fazer algo em relação a isso -- de fato desenhar e concordar em tudo -- por volta de 3 anos atras, mais ou menos quando eu comecei aqui no Google quando eu consegui dedicar mais tempo ao Python. Por um longo tempo eu estive forçando o projeto, fazendo com que as pessoas ficassem empolgadas. Eu dei palestras anuais na PyCon, na Euro Python e outras conferências. Nos últimos 12 meses, na maior parte do tempo, eu fiquei sentado aproveitando o momento enquanto a comunidade estava terminando os detalhes finais e se preparando para o release.
Uma vez que o Python 3.0 quebra a compatibilidade com o Python 2.x seu release foi coordenado com o release do Python 2.6 que fornece uma forma conveniente e segura de experimentar várias das novas funcionalidades. Como foi feito em versões anteriores do Python, a 2.6 é totalmente compatível com versões anteriores mas também contém muitas das novidades do Python 3.0 (algumas disponíveis usando a inteligente declaração "from __future__ import").
Novas funcionalidades do Python 3.0
Guido disse que as principais funcionalidades do Python 3.0 são, um suporte a Unicode muito melhor e limpo de 'sujeiras'. De fato o suporte completo a unicode é um dos principais aspectos que mudou. Guido escreveu:
Todo o texto é unicode; entretanto, Unicode codificado é representado como dado binário ... Com ouma consequência desta mudança na filosofia, muito do código que usa Unicode, codificação ou dados binários provavelmente terá que mudar. A mudança é para melhor, já que no mundo 2.x haviam vários bugs relacionados com a mistura de texto codificado e não codificado.
Enauqnto o Python 2.x suporta Unicode, havia tanto um (antigo) tipo str quanto um (novo) tipo unicode. No Python 3.0 todas as strings são unicode (str é agora unicode string) e há um novo tipo chamado bytes para armazenar sequencias de bytes.
Outras mudanças no Python 3.0 incluem:
- Print é uma função - A declaração print foi substituida com uma função print(), com argumentos keyword para substituir a maior parte da sintaxe especial do antigo print (pode-se experimentar esta funcionalidade no Python 2.6 usando from_future_ import printf_function. Mais sobre isso em PEP 3105 -- Make print a function.
- Views e Iterators ao invés de Lists - Algumas APIs bem conhecidas não retorna mais objetos list. Os métodos
dict.iterkeys(),dict.itervalues()edict.iteritems()nos dicionários foram removidos. Ao invés deles você pode usar.keys(),.values()e.items(), que foram modificados para retorna objetos leves, similares a set ao invés de uma lista que é uma cópia das chaves ou valores. A vantagem aqui é a habilidade de executar operaçõessetem chaves e itens sem ter de copiá-los. - Integers - removida a ambiguidade do operador ('/'), que agora sempre retorna um float. Nas versões anteriores ele retornava o mínimo do resultado matemático da divisão se os argumentos eram int ou long, mas retornava uma aproximação do resultado da divisão se os argumentos eram float ou complex. Esta funcionalidade pode ser usada na versão 2.6 usando o from __future__ import division. Mais sobre isso no PEP 238 -- Changing the Division Operator.
- Várias mudançás de sintaxe
Muito tempo foi investido para tornar a transição da versão 3.0 tão fácil quanto possível. Em adição aos backports de muitas funcionalidades para a versão 2.6, há uma nova opção de linha de comando que habilita warnings sobre funcionalidades que serão removidas no Python 3.0. Você pode executar o código com esta opção para ver quanto trabalho será necessário para portar seu código para o 3.0. Além disso, uma nova ferramenta chamada "2to3" que é um programa Python que lê o código fonte em Python 2.x e aplica uma série de correções para transformar em um código válido do Python 3.0. Guido também acrescentou:
Atualmente, a ferramente 2to3 tem um modo onde ao invés de modificar o código no local, que é o comportamento normal, você também pode pedir para apenas imprimir os diffs do que vai mudar. Se você quiser, você pode apenas revisar arquivo por arquivo e decidir, "Oh, sim. Está fazendo a coisa certa." ou se você revisar cuidadosamente, poderia descobrir que há pelo menos um caso em que a ferramenta não faz a coisa certa. Você pode então pegar aquele patch e manualmente alterá-lo para o que você acha que deve ser aplicado. Dessa forma a ferramenta pode ainda ajudar você com boa parte do trabalho. Esse foi um precedento do que está acontecendo no mundo do Python 2.6 para o Python 3.0.
Deve-se desenvolver em Python 2.6 ou Python 3.0? Guido fez esta observação:
... isos é uma escolha muito pessoal, decidir usar o 3.0 ou o 2.6. Você não corre o risco deficar pra trás se tomar uma atitude conservadora neste momento. O 2.6 será tão bem suportado pelo mesmo grupo de desenvolvedores do core Python quanto o 3.0. AO mesmo tempo, nós também não vamos perder a ênfase na importância e qualidade do 3.0. Então se você não possue impedimentos externos como dependências ou pacotes de terceiros que não foram portados para o 3.0 ainda ou não esta'trabalhando em um ambiente onde todo mundo está usando outra versão.
Um dos aspectos mais conhecidos do Python e da comunidade Python são os avanços conservadores de versão em versão com muita preocupação em relação à compatibilidade retroativa. Agora a comunidade Python mostrou que pode fazer o que outros só sonham fazer - produzir uma versão melhor da linguagem ao custo de compatibilidade retroativa. A Comunidade Java tem flertado com esta idéia por anos, mas desde a versão 1. (vulgo Java2) o "feio e ruim" não foi tocado por medo de quebrar os códigos existentes.