O que há de novo no Python 3.0
******************************

Autor:
   Guido van Rossum

Este artigo explica os novos recursos do Python 3.0, em comparação com
o 2.6. O Python 3.0, também conhecido como "Python 3000" ou "Py3K", é
o primeiro lançamento do Python *intencionalmente incompatível com
versões anteriores*. O Python 3.0 foi lançado em 3 de dezembro de
2008. Há mais mudanças do que em um lançamento típico, e mais que são
importantes para todos os usuários do Python. No entanto, depois de
digerir as mudanças, você verá que o Python realmente não mudou tanto
assim -- em geral, estamos principalmente corrigindo aborrecimentos
bem conhecidos, e removendo muita sujeira antiga.

Este artigo não tenta fornecer uma especificação completa de todos os
novos recursos, mas tenta dar uma visão geral conveniente. Para
detalhes completos, você deve consultar a documentação do Python 3.0
e/ou as muitas PEPs referenciadas no texto. Se você quiser entender a
implementação completa e a lógica de design para um recurso
específico, as PEPs geralmente têm mais detalhes do que a documentação
regular; mas observe que as PEPs geralmente não são mantidas
atualizadas depois que um recurso foi totalmente implementado.

Devido a restrições de tempo, este documento não está tão completo
quanto deveria ser. Como sempre para um novo lançamento, o arquivo
"Misc/NEWS" na distribuição fonte contém uma riqueza de informações
detalhadas sobre cada pequena coisa que foi alterada.


Obstáculos comuns
=================

Esta seção lista as poucas mudanças que provavelmente irão lhe
atrapalhar se você estiver acostumado com o Python 2.5.


print é uma função
------------------

A instrução "print" foi substituída por uma função "print()", com
argumentos nomeados para substituir a maior parte da sintaxe especial
da antiga instrução "print" (**PEP 3105**). Exemplos:

   Antigo: print "The answer is", 2*2
   Novo: print("The answer is", 2*2)

   Antigo: print x,           # Vírgula no final suprime nova linha
   Novo: print(x, end=" ")  # Anexa um espaço em vez de uma nova linha

   Antigo: print              # Exibe uma nova linha
   Novo: print()            # Você precisa chamar a função!

   Antigo: print >>sys.stderr, "fatal error"
   Novo: print("fatal error", file=sys.stderr)

   Antigo: print (x, y)       # Exibe repr((x, y))
   Novo: print((x, y))      # Não é o mesmo que print(x, y)!

Você também pode personalizar o separador entre itens, por exemplo:

   print("Há <", 2**32, "> possibilidades!", sep="")

que produz:

   Há <4294967296> possibilidades!

Nota:

* A função "print()" não tem suporte ao recurso "softspace" da antiga
  instrução "print". Por exemplo, no Python 2.x, "print "A\n", "B""
  escreveria ""A\nB\n""; mas no Python 3.0, "print("A\n", "B")"
  escreve ""A\n B\n"".

* Inicialmente, você vai se pegar digitando o antigo "print x"
  bastante no modo interativo. É hora de treinar seus dedos para
  digitar "print(x)" em vez disso!

* Ao usar a ferramenta de conversão de fonte para fonte "2to3", todas
  as instruções "print" são automaticamente convertidas em chamadas de
  função "print()", então isso geralmente não é um problema para
  projetos maiores.


Visualizações e iteradores em vez de listas
-------------------------------------------

Algumas APIs conhecidas não retornam mais listas:

* Os métodos "dict.keys()", "dict.items()" e "dict.values()" de "dict"
  retornam visualizações, ou "views", em vez de listas. Por exemplo,
  isso não funciona mais: "k = d.keys(); k.sort()". Use "k =
  sorted(d)" em vez disso (isso funciona no Python 2.5 também e é
  igualmente eficiente).

* Além disso, os métodos "dict.iterkeys()", "dict.iteritems()" e
  "dict.itervalues()" não são mais suportados.

* "map()" e "filter()" retornam iteradores. Se você realmente precisa
  de uma lista e as sequências de entrada são todas de comprimento
  igual, uma solução rápida é envolver "map()" em "list()", por
  exemplo, "list(map(...))", mas uma solução melhor é frequentemente
  usar uma compreensão de lista (especialmente quando o código
  original usa "lambda"), ou reescrever o código para que ele não
  precise de uma lista. Particularmente complicado é "map()" invocado
  para os efeitos colaterais da função; a transformação correta é usar
  um laço "for" regular (já que criar uma lista seria apenas
  desperdício).

  Se as sequências de entrada não tiverem o mesmo comprimento, "map()"
  irá parar no término da mais curta das sequências. Para
  compatibilidade total com "map()" do Python 2.x, também envolva as
  sequências em "itertools.zip_longest()", por exemplo, "map(func,
  *sequences)" se torna "list(map(func,
  itertools.zip_longest(*sequences)))".

* "range()" agora se comporta como "xrange()" costumava se comportar,
  exceto que funciona com valores de tamanho arbitrário. Este último
  não existe mais.

* "zip()" agora retorna um iterador.


Comparações de ordenação
------------------------

O Python 3.0 simplificou as regras para ordenar comparações:

* Os operadores de comparação de ordenação ("<", "<=", ">=", ">")
  levantam uma exceção TypeError quando os operandos não têm uma
  ordenação natural significativa. Assim, expressões como "1 < ''", "0
  > None" ou "len <= len" não são mais válidas e, por exemplo, "None <
  None" levanta "TypeError" em vez de retornar "False". Um corolário é
  que classificar uma lista heterogênea não faz mais sentido -- todos
  os elementos devem ser comparáveis entre si. Observe que isso não se
  aplica aos operadores "==" e "!=": objetos de diferentes tipos
  incomparáveis sempre são comparados de forma diferente entre si.

* "sorted()" e "list.sort()" não aceitam mais o argumento *cmp*
  fornecendo uma função de comparação. Use o argumento *key* em vez
  disso. N.B. os argumentos *key* e *reverse* agora são "somente-
  nomeados".

* A função "cmp()" deve ser tratada como extinta, e o método especial
  "__cmp__()" não é mais suportado. Use "__lt__()" para classificação,
  "__eq__()" com "__hash__()" e outras comparações avançadas conforme
  necessário. (Se você realmente precisa da funcionalidade "cmp()",
  pode usar a expressão "(a > b) - (a < b)" como o equivalente para
  "cmp(a, b)".)


Inteiros
--------

* **PEP 237**: Essencialmente, "long" foi renomeado para "int". Ou
  seja, há apenas um tipo integral embutido, chamado "int"; mas ele se
  comporta principalmente como o antigo tipo "long".

* **PEP 238**: Uma expressão como "1/2" retorna um float. Use "1//2"
  para obter o comportamento de truncamento. (A última sintaxe existe
  há anos, pelo menos desde o Python 2.2.)

* A constante "sys.maxint" foi removida, pois não há mais um limite
  para o valor de inteiros. No entanto, "sys.maxsize" pode ser usado
  como um inteiro maior do que qualquer lista prática ou índice de
  string. Ele está em conformidade com o tamanho inteiro "natural" da
  implementação e é tipicamente o mesmo que "sys.maxint" em versões
  anteriores na mesma plataforma (assumindo as mesmas opções de
  construção).

* O "repr()" de um inteiro longo não inclui mais o "L" final, então o
  código que remove esse caractere incondicionalmente cortará o último
  dígito. (Use "str()" em vez disso.)

* Literais octais não estão mais no formato "0720"; em vez disso, use
  "0o720".


Texto vs. Dados em vez de Unicode vs. 8 bits
--------------------------------------------

Tudo o que você achava que sabia sobre dados binários e Unicode mudou.

* O Python 3.0 usa os conceitos de *texto* e *dados* (binários) em vez
  de strings Unicode e strings de 8 bits. Todo texto é Unicode; no
  entanto, o Unicode *codificado* é representado como dados binários.
  O tipo usado para armazenar texto é "str", o tipo usado para
  armazenar dados é "bytes". A maior diferença com a situação 2.x é
  que qualquer tentativa de misturar texto e dados no Python 3.0
  levanta "TypeError", enquanto que se você misturasse strings Unicode
  e de 8 bits no Python 2.x, funcionaria se a string de 8 bits
  contivesse apenas bytes de 7 bits (ASCII), mas você obteria
  "UnicodeDecodeError" se contivesse valores não ASCII. Esse
  comportamento específico de valor causou inúmeras caras tristes ao
  longo dos anos.

* Como consequência dessa mudança na filosofia, praticamente todo
  código que usa Unicode, codificações ou dados binários provavelmente
  terá que mudar. A mudança é para melhor, pois no mundo 2.x havia
  vários bugs relacionados à mistura de texto codificado e não
  codificado. Para estar preparado no Python 2.x, comece a usar
  "unicode" para todo texto não codificado e "str" apenas para dados
  binários ou codificados. Então a ferramenta "2to3" fará a maior
  parte do trabalho para você.

* Você não pode mais usar literais "u"..."" para texto Unicode. No
  entanto, você deve usar literais "b"..."" para dados binários.

* Como os tipos "str" e "bytes" não podem ser misturados, você deve
  sempre converter explicitamente entre eles. Use "str.encode()" para
  ir de "str" para "bytes", e "bytes.decode()" para ir de "bytes" para
  "str". Você também pode usar "bytes(s, encoding=...)" e "str(b,
  encoding=...)", respectivamente.

* Assim como "str", o tipo "bytes" é imutável. Há um tipo *mutável*
  separado para armazenar dados binários em buffer, "bytearray". Quase
  todas as APIs que aceitam "bytes" também aceitam "bytearray". A API
  mutável é baseada em "collections.MutableSequence".

* Todas as contrabarras em literais de strings brutas são
  interpretadas literalmente. Isso significa que os escapes "'\U'" e
  "'\u'" em strings brutas não são tratados de forma especial. Por
  exemplo, "r'\u20ac'" é uma string de 6 caracteres no Python 3.0,
  enquanto no 2.6, "ur'\u20ac'" era o único caractere "euro". (É claro
  que essa mudança afeta apenas literais de strings brutas; o
  caractere euro é "'\u20ac'" no Python 3.0.)

* O tipo abstrato embutido "basestring" foi removido. Use "str" em vez
  disso. Os tipos "str" e "bytes" não têm funcionalidade suficiente em
  comum para garantir uma classe base compartilhada. A ferramenta
  "2to3" (veja abaixo) substitui cada ocorrência de "basestring" por
  "str".

* Arquivos abertos como arquivos texto (ainda o modo padrão para
  "open()") sempre usam uma codificação para mapear entre strings (na
  memória) e bytes (no disco). Arquivos binários (abertos com um "b"
  no argumento mode) sempre usam bytes na memória. Isso significa que
  se um arquivo for aberto usando um modo ou codificação incorretos, a
  E/S provavelmente falhará ruidosamente, em vez de produzir dados
  incorretos silenciosamente. Isso também significa que até mesmo
  usuários Unix terão que especificar o modo correto (texto ou
  binário) ao abrir um arquivo. Há uma codificação padrão dependente
  da plataforma, que em plataformas Unixy pode ser definida com a
  variável de ambiente "LANG" (e às vezes também com algumas outras
  variáveis de ambiente relacionadas à localidade específicas da
  plataforma). Em muitos casos, mas não em todos, o padrão do sistema
  é UTF-8; você nunca deve contar com esse padrão. Qualquer aplicação
  que leia ou escreva mais do que texto ASCII puro provavelmente deve
  ter uma maneira de substituir a codificação. Não há mais necessidade
  de usar os fluxos com reconhecimento de codificação no módulo
  "codecs".

* Os valores iniciais de "sys.stdin", "sys.stdout" e "sys.stderr"
  agora são arquivos texto somente unicode (ou seja, são instâncias de
  "io.TextIOBase"). Para ler e gravar dados de bytes com esses fluxos,
  você precisa usar o atributo "io.TextIOBase.buffer" deles.

* Nomes de arquivo são passados e retornados de APIs como strings
  (Unicode). Isso pode apresentar problemas específicos de plataforma
  porque em algumas plataformas nomes de arquivo são strings de bytes
  arbitrárias. (Por outro lado, no Windows nomes de arquivo são
  armazenados nativamente como Unicode.) Como solução alternativa, a
  maioria das APIs (por exemplo, "open()" e muitas funções no módulo
  "os") que aceitam nomes de arquivo aceitam objetos "bytes" assim
  como strings, e algumas APIs têm uma maneira de pedir um valor de
  retorno "bytes". Assim, "os.listdir()" retorna uma lista de
  instâncias "bytes" se o argumento for uma instância "bytes", e
  "os.getcwdb()" retorna o diretório de trabalho atual como uma
  instância "bytes". Observe que quando "os.listdir()" retorna uma
  lista de strings, os nomes de arquivos que não podem ser
  decodificados corretamente são omitidos em vez de levantar
  "UnicodeError".

* Algumas APIs de sistema como "os.environ" e "sys.argv" também podem
  apresentar problemas quando os bytes disponibilizados pelo sistema
  não são interpretáveis usando a codificação padrão. Definir a
  variável "LANG" e executar o programa novamente é provavelmente a
  melhor abordagem.

* **PEP 3138**: A "repr()" de uma string não escapa mais caracteres
  não-ASCII. No entanto, ele ainda escapa caracteres de controle e
  pontos de código com status não imprimível no padrão Unicode.

* **PEP 3120**: A codificação de fontes padrão agora é UTF-8.

* **PEP 3131**: Letras não ASCII agora são permitidas em
  identificadores. (No entanto, a biblioteca padrão permanece somente
  ASCII, com exceção dos nomes dos colaboradores nos comentários.)

* Os módulos "StringIO" e "cStringIO" se foram. Em vez disso, importe
  o módulo "io" e use "io.StringIO" ou "io.BytesIO" para texto e
  dados, respectivamente.

* Veja também o guia Unicode, que foi atualizado para o Python 3.0.


Visão geral das alterações da sintaxe
=====================================

Esta seção fornece uma breve visão geral de cada mudança *sintática*
no Python 3.0.


Nova sintaxe
------------

* **PEP 3107**: Anotações de argumento de função e valor de retorno.
  Isso fornece uma maneira padronizada de anotar os parâmetros e o
  valor de retorno de uma função. Não há semântica anexada a essas
  anotações, exceto que elas podem ser introspectadas em tempo de
  execução usando o atributo "__annotations__". A intenção é encorajar
  a experimentação por meio de metaclasses, decoradores ou frameworks.

* **PEP 3102**: Argumentos somente-nomeados. Parâmetros nomeados que
  ocorrem após "*args" na lista de parâmetros *devem* ser
  especificados usando a sintaxe dos nomes na chamada. Você também
  pode usar um "*" simples na lista de parâmetros para indicar que não
  aceita uma lista de argumentos de comprimento variável, mas tem
  argumentos somente-nomeados.

* Argumentos nomeados são permitidos após a lista de classes base em
  uma definição de classe. Isso é usado pela nova convenção para
  especificar uma metaclasse (veja a próxima seção), mas pode ser
  usado para outros propósitos também, desde que a metaclasse dê
  suporte.

* **PEP 3104**: instrução "nonlocal". Usando "nonlocal x", agora você
  pode atribuir diretamente a uma variável em um escopo externo (mas
  não global). "nonlocal" é uma nova palavra reservada.

* **PEP 3132**: Desempacotamento iterável estendido. Agora você pode
  escrever coisas como "a, b, *rest = some_sequence". E até mesmo
  "*rest, a = stuff". O objeto "rest" é sempre uma lista
  (possivelmente vazia); o lado direito pode ser qualquer iterável.
  Exemplo:

     (a, *rest, b) = range(5)

  Isso define *a* como "0", *b* como "4" e *rest* como "[1, 2, 3]".

* Compreensões de dicionário: "{k: v for k, v in stuff}" significa a
  mesma coisa que "dict(stuff)", mas é mais flexível. (Isto é **PEP
  274** justificada. :-)

* Definir literais, por exemplo, "{1, 2}". Note que "{}" é um
  dicionário vazio; use "set()" para um conjunto vazio. Compreensões
  de conjuntos também são suportadas; por exemplo, "{x for x in
  stuff}" significa a mesma coisa que "set(stuff)", mas é mais
  flexível.

* Novos literais octais, por exemplo, "0o720" (já em 2.6). Os antigos
  literais octais ("0720") se foram.

* Novos literais binários, por exemplo, "0b1010" (já em 2.6), e há uma
  nova função embutida correspondente, "bin()".

* Literais de bytes são introduzidos com um "b" ou "B" no início, e há
  uma nova função embutida correspondente, "bytes()".


Sintaxe alterada
----------------

* **PEP 3109** e **PEP 3134**: nova sintaxe da instrução "raise":
  "raise [*expr* [from *expr*]]". Veja abaixo.

* "as" e "with" agora são palavras reservadas. (Desde a versão 2.6, na
  verdade.)

* "True", "False" e "None" são palavras reservadas. (A versão 2.6 já
  aplicava parcialmente as restrições em "None".)

* Alteração de "except" *exc*, *var* para "except" *exc* "as" *var*.
  Veja a **PEP 3110**.

* **PEP 3115**: Nova sintaxe de metaclasse. Em vez de:

     class C:
         __metaclass__ = M
         ...

  agora você deve usar:

     class C(metaclass=M):
         ...

  A variável global do módulo "__metaclass__" não é mais suportada.
  (Era uma ajuda para facilitar a mudança do padrão para classes de
  novo estilo sem derivar cada classe de "object".)

* As compreensões de lista não têm mais suporte a mais a forma
  sintática "[... for *var* in *item1*, *item2*, ...]". Use "[... for
  *var* in (*item1*, *item2*, ...)]" em vez disso. Observe também que
  as compreensões de lista têm semântica diferente: elas estão mais
  próximas do açúcar sintático para uma expressão geradora dentro de
  um construtor "list()" e, em particular, as variáveis de controle de
  laço não são mais vazadas para o escopo circundante.

* As *reticências* ("...") podem ser usadas como uma expressão atômica
  em qualquer lugar. (Anteriormente, eram permitidas apenas em
  fatias.) Além disso, agora *devem* ser escritas como "...".
  (Anteriormente, também poderiam ser escritas como ". . .", por um
  mero acidente da gramática.)


Sintaxe removida
----------------

* **PEP 3113**: Desempacotamento de parâmetro de tupla removido. Você
  não pode mais escrever "def foo(a, (b, c)): ...". Em vez disso, use
  "def foo(a, b_c): b, c = b_c".

* Removidos backticks (use "repr()").

* Removido "<>" (use "!=").

* Removida palavra reservada: "exec()" não é mais uma palavra
  reservada; ela permanece como uma função. (Felizmente a sintaxe da
  função também era aceita nas versões 2.x.) Observe também que
  "exec()" não aceita mais um argumento de fluxo; em vez de "exec(f)"
  você pode usar "exec(f.read())".

* Literais de inteiro não mais têm suporte a um "l" ou "L" final.

* Literais de string não mais têm suporte a um "u" ou "U" no início.

* A sintaxe "from" *módulo* "import" "*" é permitida somente no nível
  do módulo, não mais dentro de funções.

* A única sintaxe aceitável para importações relativas é "from
  .[*module*] import *name*". Todos as formas de "import" que não
  começam com "." são interpretadas como importações absolutas. (**PEP
  328**)

* As classes clássicas se foram.


Mudanças já presentes no Python 2.6
===================================

Como muitos usuários provavelmente fazem o salto direto do Python 2.5
para o Python 3.0, esta seção lembra o leitor dos novos recursos que
foram originalmente projetados para o Python 3.0, mas que foram
portados de volta para o Python 2.6. As seções correspondentes em O
que há de novo no Python 2.6 devem ser consultadas para descrições
mais longas.

* PEP 343: The 'with' statement. A instrução "with" agora é um recurso
  padrão e não precisa mais ser importada de "__future__". Confira
  também Writing Context Managers e The contextlib module.

* PEP 366: Explicit Relative Imports From a Main Module. Isso aumenta
  a utilidade da opção "-m" quando o módulo referenciado reside em um
  pacote.

* PEP 370: Per-user site-packages Directory.

* PEP 371: The multiprocessing Package.

* PEP 3101: Advanced String Formatting. Nota: a descrição da versão
  2.6 menciona o método "format()" para strings de 8 bits e Unicode.
  No 3.0, apenas o tipo "str" (strings de texto com suporte a Unicode)
  tem suporte a esse método; o tipo "bytes" não. O plano é
  eventualmente tornar esta a única API para formatação de strings e
  começar a descontinuar o operador "%" no Python 3.1.

* PEP 3105: print As a Function. Este é agora um recurso padrão e não
  precisa mais ser importado de "__future__". Mais detalhes foram
  fornecidos acima.

* PEP 3110: Exception-Handling Changes. A sintaxe "except" *exc* "as"
  *var* agora é padrão e "except" *exc*, *var* não é mais suportado.
  (Claro, a parte "as" *var* ainda é opcional.)

* PEP 3112: Byte Literals. A notação de literal de string "b"..."" (e
  suas variantes como "b'...'", "b"""..."""" e "br"..."") agora produz
  um literal do tipo "bytes".

* PEP 3116: New I/O Library. O módulo "io" agora é a maneira padrão de
  fazer E/S de arquivo. A função embutida "open()" agora é um apelido
  para "io.open()" e tem argumentos nomeados adicionais *encoding*,
  *errors*, *newline* e *closefd*. Observe também que um argumento
  *mode* inválido agora levanta "ValueError", não "IOError". O objeto
  arquivo binário subjacente a um objeto arquivo texto pode ser
  acessado como "f.buffer" (mas tome cuidado, pois o objeto texto
  mantém um buffer de si mesmo para acelerar as operações de
  codificação e decodificação).

* PEP 3118: Revised Buffer Protocol. A antiga função embutida
  "buffer()" agora realmente se foi; a nova função embutida
  "memoryview()" fornece funcionalidade (principalmente) semelhante.

* PEP 3119: Abstract Base Classes. O módulo "abc" e as ABCs definidas
  no módulo "collections" desempenham um papel um pouco mais
  proeminente na linguagem agora, e tipos embutidos de coleção como
  "dict" e "list" estão em conformidade com as ABCs
  "collections.MutableMapping" e "collections.MutableSequence",
  respectivamente.

* PEP 3127: Integer Literal Support and Syntax. Conforme mencionado
  acima, a nova notação de literal octal é a única suportada, e
  literais binários foram adicionados.

* PEP 3129: Class Decorators.

* PEP 3141: A Type Hierarchy for Numbers. O módulo "numbers" é outro
  novo uso de ABCs, definindo a "torre numérica" do Python. Observe
  também o novo módulo "fractions" que implementa "numbers.Rational".


Mudanças na biblioteca
======================

Devido a restrições de tempo, este documento não cobre exaustivamente
as mudanças muito extensas na biblioteca padrão. **PEP 3108** é a
referência para as principais mudanças na biblioteca. Aqui está uma
revisão resumida:

* Muitos módulos antigos foram removidos. Alguns, como "gopherlib"
  (não mais usado) e "md5" (substituído por "hashlib"), já tinham sido
  descontinuados pela **PEP 4**. Outros foram removidos como resultado
  da remoção do suporte para várias plataformas, como Irix, BeOS e Mac
  OS 9 (veja **PEP 11**). Alguns módulos também foram selecionados
  para remoção no Python 3.0 devido à falta de uso ou porque existe
  uma substituição melhor. Veja **PEP 3108** para uma lista exaustiva.

* O pacote "bsddb3" foi removido porque sua presença na biblioteca
  padrão principal provou ao longo do tempo ser um fardo particular
  para os desenvolvedores principais devido à instabilidade dos testes
  e ao cronograma de lançamento do Berkeley DB. No entanto, o pacote
  está vivo e bem, mantido externamente em
  https://www.jcea.es/programacion/pybsddb.htm.

* Alguns módulos foram renomeados porque seu nome antigo desobedecia a
  **PEP 8**, ou por vários outros motivos. Aqui está a lista:

  +-------------------------+-------------------------+
  | Antigo nome             | Novo nome               |
  |=========================|=========================|
  | _winreg                 | winreg                  |
  +-------------------------+-------------------------+
  | ConfigParser            | configparser            |
  +-------------------------+-------------------------+
  | copy_reg                | copyreg                 |
  +-------------------------+-------------------------+
  | Queue                   | queue                   |
  +-------------------------+-------------------------+
  | SocketServer            | socketserver            |
  +-------------------------+-------------------------+
  | markupbase              | _markupbase             |
  +-------------------------+-------------------------+
  | repr                    | reprlib                 |
  +-------------------------+-------------------------+
  | test.test_support       | test.support            |
  +-------------------------+-------------------------+

* Um padrão comum no Python 2.x é ter uma versão de um módulo
  implementada em Python puro, com uma versão acelerada opcional
  implementada como uma extensão C; por exemplo, "pickle" e "cPickle".
  Isso coloca o fardo de importar a versão acelerada e recorrer à
  versão Python pura em cada usuário desses módulos. No Python 3.0, as
  versões aceleradas são consideradas detalhes de implementação das
  versões Python puras. Os usuários devem sempre importar a versão
  padrão, que tenta importar a versão acelerada e recorrer à versão
  Python pura. O par "pickle" / "cPickle" recebeu esse tratamento. O
  módulo "profile" está na lista para 3.1. O módulo "StringIO" foi
  transformado em uma classe no módulo "io".

* Alguns módulos relacionados foram agrupados em pacotes e,
  geralmente, os nomes dos submódulos foram simplificados. Os novos
  pacotes resultantes são:

  * "dbm" ("anydbm", "dbhash", "dbm", "dumbdbm", "gdbm", "whichdb").

  * "html" ("HTMLParser", "htmlentitydefs").

  * "http" ("httplib", "BaseHTTPServer", "CGIHTTPServer",
    "SimpleHTTPServer", "Cookie", "cookielib").

  * "tkinter" (todos os módulos relacionados a "Tkinter", exceto
    "turtle"). O público-alvo de "turtle" não se importa muito com
    "tkinter". Observe também que, a partir do Python 2.6, a
    funcionalidade de "turtle" foi bastante aprimorada.

  * "urllib" ("urllib", "urllib2", "urlparse", "robotparse").

  * "xmlrpc" ("xmlrpclib", "DocXMLRPCServer", "SimpleXMLRPCServer").

Algumas outras mudanças nos módulos da biblioteca padrão, não cobertas
pela **PEP 3108**:

* "sets" eliminado. Use a classe embutida "set()".

* Limpeza do módulo "sys": removidos "sys.exitfunc()",
  "sys.exc_clear()", "sys.exc_type", "sys.exc_value",
  "sys.exc_traceback". (Observe que "sys.last_type" etc. permanecem.)

* Limpeza do tipo "array.array": os métodos "read()" e "write()" foram
  removidos; use "fromfile()" e "tofile()" em vez disso. Além disso, o
  typecode "'c'" para vetor foi removido -- use "'b'" para bytes ou
  "'u'" para caracteres Unicode.

* Cleanup of the "operator" module: removed "sequenceIncludes()" and
  "isCallable()".

* Limpeza do módulo "thread": "acquire_lock()" e "release_lock()"
  foram removidos; use "acquire()" e "release()" em vez disso.

* Cleanup of the "random" module: removed the "jumpahead()" API.

* O módulo "new" foi removido.

* The functions "os.tmpnam()", "os.tempnam()" and "os.tmpfile()" have
  been removed in favor of the "tempfile" module.

* O módulo "tokenize" foi alterado para funcionar com bytes. O ponto
  de entrada principal agora é "tokenize.tokenize()", em vez de
  generate_tokens.

* "string.letters" and its friends ("string.lowercase" and
  "string.uppercase") are gone.  Use "string.ascii_letters" etc.
  instead.  (The reason for the removal is that "string.letters" and
  friends had locale-specific behavior, which is a bad idea for such
  attractively named global "constants".)

* Renamed module "__builtin__" to "builtins" (removing the
  underscores, adding an 's').  The "__builtins__" variable found in
  most global namespaces is unchanged.  To modify a builtin, you
  should use "builtins", not "__builtins__"!


**PEP 3101**: Uma nova abordagem para formatação de strings
===========================================================

* Um novo sistema para operações de formatação de strings embutidas
  substitui o operador de formatação de strings "%". (No entanto, o
  operador "%" ainda é suportado; ele será descontinuado no Python 3.1
  e removido da linguagem em algum momento posterior.) Leia a **PEP
  3101** para obter informações completas.


Mudanças para exceções
======================

As APIs para levantar e capturar exceções foram limpas e novos
recursos poderosos foram adicionados:

* **PEP 352**: Todas as exceções devem ser derivadas (direta ou
  indiretamente) de "BaseException". Esta é a raiz da hierarquia de
  exceções. Isso não é novo como recomendação, mas o *requisito* para
  herdar de "BaseException" é novo. (O Python 2.6 ainda permitia que
  classes clássicas fossem levantadas e não colocava nenhuma restrição
  sobre o que você pode capturar.) Como consequência, exceções de
  string estão finalmente verdadeira e completamente mortas.

* Quase todas as exceções devem derivar de "Exception";
  "BaseException" deve ser usado apenas como uma classe base para
  exceções que devem ser manipuladas apenas no nível superior, como
  "SystemExit" ou "KeyboardInterrupt". O idioma recomendado para
  manipular todas as exceções, exceto para esta última categoria, é
  usar "except" "Exception".

* "StandardError" was removed.

* Exceptions no longer behave as sequences.  Use the "args" attribute
  instead.

* **PEP 3109**: levantando exceções. Agora você deve usar "raise
  *Exception*(*args*)" em vez de "raise *Exception*, *args*". Além
  disso, você não pode mais especificar explicitamente um traceback
  (situação da pilha de execução); em vez disso, se você *precisar*
  fazer isso, você pode atribuir diretamente ao atributo
  "__traceback__" (veja abaixo).

* **PEP 3110**: Capturando exceções. Agora você deve usar "except
  *SomeException* as *variable*" em vez de "except *SomeException*,
  *variable*". Além disso, a variável *variable* é explicitamente
  excluída quando o bloco "except" é deixado.

* **PEP 3134**: Encadeamento de exceções. Existem dois casos:
  encadeamento implícito e encadeamento explícito. O encadeamento
  implícito acontece quando uma exceção é levantada em um bloco
  manipulador "except" ou "finally". Isso geralmente acontece devido a
  um bug no bloco do manipulador; chamamos isso de exceção
  *secundária*. Nesse caso, a exceção original (que estava sendo
  manipulada) é salva como o atributo "__context__" da exceção
  secundária. O encadeamento explícito é invocado com esta sintaxe:

     raise SecondaryException() from primary_exception

  (onde *primary_exception* é qualquer expressão que produz um objeto
  de exceção, provavelmente uma exceção que foi capturada
  anteriormente). Neste caso, a exceção primária é armazenada no
  atributo "__cause__" da exceção secundária. O traceback impresso
  quando uma exceção não tratada ocorre percorre a cadeia de atributos
  "__cause__" e "__context__" e imprime um traceback separado para
  cada componente da cadeia, com a exceção primária no topo. (Usuários
  Java podem reconhecer este comportamento.)

* **PEP 3134**: Objetos exceção agora armazenam seu traceback como o
  atributo "__traceback__". Isso significa que um objeto de exceção
  agora contém todas as informações pertencentes a uma exceção, e há
  menos motivos para usar "sys.exc_info()" (embora o último não seja
  removido).

* Algumas mensagens de exceção estão melhores quando o Windows falha
  ao carregar um módulo de extensão. Por exemplo, "error code 193"
  agora é "%1 is not a valid Win32 application". As strings agora
  lidam com localidades que não sejam em inglês.


Outras mudanças diversas
========================


Operadores e métodos especiais
------------------------------

* "!=" agora retorna o oposto de "==", a menos que "==" retorne
  "NotImplemented".

* O conceito de "métodos não vinculados" foi removido da linguagem. Ao
  referenciar um método como um atributo de classe, agora você obtém
  um objeto função simples.

* "__getslice__()", "__setslice__()" and "__delslice__()" were killed.
  The syntax "a[i:j]" now translates to "a.__getitem__(slice(i, j))"
  (or "__setitem__()" or "__delitem__()", when used as an assignment
  or deletion target, respectively).

* **PEP 3114**: o método padrão "next()" foi renomeado para
  "__next__()".

* The "__oct__()" and "__hex__()" special methods are removed --
  "oct()" and "hex()" use "__index__()" now to convert the argument to
  an integer.

* Removed support for "__members__" and "__methods__".

* Os atributos de função chamados "func_X" foram renomeados para usar
  o formato "__X__", liberando esses nomes no espaço de nomes de
  atributos de função para atributos definidos pelo usuário. A saber,
  "func_closure", "func_code", "func_defaults", "func_dict",
  "func_doc", "func_globals", "func_name" foram renomeados para
  "__closure__", "__code__", "__defaults__", "__dict__", "__doc__",
  "__globals__", "__name__", respectivamente.

* "__nonzero__()" agora é "__bool__()".


Funções embutidas
-----------------

* **PEP 3135**: Nova função "super()". Agora você pode invocar
  "super()" sem argumentos e (presumindo que isso esteja em um método
  de instância regular definido dentro de uma instrução "class") a
  classe e instância corretas serão automaticamente escolhidas. Com
  argumentos, o comportamento de "super()" não é alterado.

* **PEP 3111**: "raw_input()" was renamed to "input()".  That is, the
  new "input()" function reads a line from "sys.stdin" and returns it
  with the trailing newline stripped. It raises "EOFError" if the
  input is terminated prematurely. To get the old behavior of
  "input()", use "eval(input())".

* Uma nova função embutido "next()" foi adicionada para chamar o
  método "__next__()" em um objeto.

* A estratégia de arredondamento da função "round()" e o tipo de
  retorno foram alterados. Casos exatos de meio caminho agora são
  arredondados para o resultado par mais próximo em vez de para longe
  de zero. (Por exemplo, "round(2.5)" agora retorna "2" em vez de
  "3".) "round(x[, n])" agora delega para "x.__round__([n])" em vez de
  sempre retornar um float. Geralmente retorna um inteiro quando
  chamado com um único argumento e um valor do mesmo tipo que "x"
  quando chamado com dois argumentos.

* Moved "intern()" to "sys.intern()".

* Removed: "apply()".  Instead of "apply(f, args)" use "f(*args)".

* Removed "callable()".  Instead of "callable(f)" you can use
  "isinstance(f, collections.Callable)".  The "operator.isCallable()"
  function is also gone.

* Removed "coerce()".  This function no longer serves a purpose now
  that classic classes are gone.

* Removed "execfile()".  Instead of "execfile(fn)" use
  "exec(open(fn).read())".

* Removed the "file" type.  Use "open()".  There are now several
  different kinds of streams that open can return in the "io" module.

* Removed "reduce()".  Use "functools.reduce()" if you really need it;
  however, 99 percent of the time an explicit "for" loop is more
  readable.

* Removed "reload()".  Use "imp.reload()".

* Removed. "dict.has_key()" -- use the "in" operator instead.


Mudanças a construções e API C
==============================

Devido a restrições de tempo, aqui está uma lista *muito* incompleta
de alterações na API C.

* O suporte para várias plataformas foi descartado, incluindo, mas não
  se limitando a Mac OS 9, BeOS, RISCOS, Irix e Tru64.

* **PEP 3118**: Nova API de Buffer.

* **PEP 3121**: Inicialização e finalização do módulo de extensão.

* **PEP 3123**: Tornando "PyObject_HEAD" conforme o padrão C.

* Não há mais suporte à API C para execução restrita.

* As APIs C "PyNumber_Coerce()", "PyNumber_CoerceEx()",
  "PyMember_Get()" e "PyMember_Set()" foram removidas.

* New C API "PyImport_ImportModuleNoBlock()", works like
  "PyImport_ImportModule()" but won't block on the import lock
  (returning an error instead).

* Renomeado o slot e o método de nível C de conversão booleana:
  "nb_nonzero" agora é "nb_bool".

* Removidas "METH_OLDARGS" e "WITH_CYCLE_GC" da API C.


Desempenho
==========

O resultado líquido das generalizações do 3.0 é que o Python 3.0
executa o benchmark pystone cerca de 10% mais lento que o Python 2.5.
Provavelmente a maior causa é a remoção do uso de maiúsculas e
minúsculas especiais para números inteiros pequenos. Há espaço para
melhorias, mas isso acontecerá após o lançamento do 3.0!


Portando para o Python 3.0
==========================

Para portar o código-fonte existente do Python 2.5 ou 2.6 para o
Python 3.0, a melhor estratégia é a seguinte:

* (Pré-requisito:) Comece com uma excelente cobertura de teste.

* Portar para o Python 2.6. Isso não deve dar mais trabalho do que o
  port médio do Python 2.x para o Python 2.(x+1). Certifique-se de que
  todos os seus testes passem.

* (Ainda usando 2.6:) Ative a opção de linha de comando "-3". Isso
  habilita avisos sobre recursos que serão removidos (ou alterados) no
  3.0. Execute seu conjunto de testes novamente e corrija o código
  sobre o qual você recebe avisos até que não haja mais avisos e todos
  os seus testes ainda passem.

* Execute o tradutor de fonte para fonte "2to3" em sua árvore de
  código-fonte. Execute o resultado da tradução no Python 3.0. Corrija
  manualmente quaisquer problemas restantes, corrigindo problemas até
  que todos os testes passem novamente.

Não é recomendado tentar escrever código-fonte que seja executado
inalterado no Python 2.6 e 3.0; você teria que usar um estilo de
codificação muito distorcido, por exemplo, evitando instruções
"print", metaclasses e muito mais. Se você estiver mantendo uma
biblioteca que precisa ter suporte ao Python 2.6 e Python 3.0, a
melhor abordagem é modificar a etapa 3 acima editando a versão 2.6 do
código-fonte e executando o tradutor "2to3" novamente, em vez de
editar a versão 3.0 do código-fonte.

Para portar extensões C para Python 3.0, consulte Portando módulos de
extensão para o Python 3.
