# 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:

    Old: print "The answer is", 2*2
    New: print("The answer is", 2*2)

    Old: print x,           # Trailing comma suppresses newline
    New: print(x, end=" ")  # Appends a space instead of a newline

    Old: print              # Prints a newline
    New: print()            # You must call the function!

    Old: print >>sys.stderr, "fatal error"
    New: print("fatal error", file=sys.stderr)

    Old: print (x, y)       # prints repr((x, y))
    New: print((x, y))      # Not the same as print(x, y)!

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

    print("There are <", 2**32, "> possibilities!", sep="")

que produz:

    There are <4294967296> possibilities!

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.

- `builtin.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.)

- The `StringIO` and `cStringIO` modules are gone. Instead, import the `io` module and use `io.StringIO` or `io.BytesIO` for text and data respectively.

- 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:

- Many old modules were removed. Some, like `gopherlib` (no longer used) and `md5` (replaced by `hashlib`), were already deprecated by PEP 4. Others were removed as a result of the removal of support for various platforms such as Irix, BeOS and Mac OS 9 (see PEP 11). Some modules were also selected for removal in Python 3.0 due to lack of use or because a better replacement exists. See PEP 3108 for an exhaustive list.

- The `bsddb3` package was removed because its presence in the core standard library has proved over time to be a particular burden for the core developers due to testing instability and Berkeley DB’s release schedule. However, the package is alive and well, externally maintained at 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:

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

- A common pattern in Python 2.x is to have one version of a module implemented in pure Python, with an optional accelerated version implemented as a C extension; for example, `pickle` and `cPickle`. This places the burden of importing the accelerated version and falling back on the pure Python version on each user of these modules. In Python 3.0, the accelerated versions are considered implementation details of the pure Python versions. Users should always import the standard version, which attempts to import the accelerated version and falls back to the pure Python version. The `pickle` / `cPickle` pair received this treatment. The `profile` module is on the list for 3.1. The `StringIO` module has been turned into a class in the `io` module.

- 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:

- Killed `sets`. Use the built-in `set()` class.

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

- Limpeza do módulo `operator`: removidos `sequenceIncludes()` e `isCallable()`.

- Cleanup of the `thread` module: `acquire_lock()` and `release_lock()` are gone; use `acquire()` and `release()` instead.

- Limpeza do módulo `random`: removida a API `jumpahead()`.

- The `new` module is gone.

- As funções `os.tmpnam()`, `os.tempnam()` e `os.tmpfile()` foram removidas em favor do módulo `tempfile`.

- 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` e seus amigos (`string.lowercase` e `string.uppercase`) se foram. Use `string.ascii_letters` etc. em vez disso. (O motivo da remoção é que `string.letters` e amigos tinham comportamento específico de localidade, o que é uma má ideia para “constantes” globais com nomes tão atraentes.)

- Renomeado o módulo `__builtin__` para `builtins` (removendo os sublinhados, adicionando um ‘s’). A variável `__builtins__` encontrada na maioria dos espaços de nomes globais não foi alterada. Para modificar um builtin, você deve usar `builtins`, não `__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` foi removida.

- As exceções não se comportam mais como sequências. Use o atributo `args` em vez disso.

- PEP 3109: Raising exceptions. You must now use `raise Exception(args)` instead of `raise Exception, args`. Additionally, you can no longer explicitly specify a traceback; instead, if you have to do this, you can assign directly to the `__traceback__` attribute (see below).

- 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: Exception chaining. There are two cases: implicit chaining and explicit chaining. Implicit chaining happens when an exception is raised in an `except` or `finally` handler block. This usually happens due to a bug in the handler block; we call this a secondary exception. In this case, the original exception (that was being handled) is saved as the `__context__` attribute of the secondary exception. Explicit chaining is invoked with this syntax:

      raise SecondaryException() from primary_exception

  (where primary_exception is any expression that produces an exception object, probably an exception that was previously caught). In this case, the primary exception is stored on the `__cause__` attribute of the secondary exception. The traceback printed when an unhandled exception occurs walks the chain of `__cause__` and `__context__` attributes and prints a separate traceback for each component of the chain, with the primary exception at the top. (Java users may recognize this behavior.)

- PEP 3134: Exception objects now store their traceback as the `__traceback__` attribute. This means that an exception object now contains all the information pertaining to an exception, and there are fewer reasons to use `sys.exc_info()` (though the latter is not removed).

- 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__()` e `__delslice__()` foram eliminados. A sintaxe `a[i:j]` agora é traduzida para `a.__getitem__(slice(i, j))` (ou `__setitem__()` ou `__delitem__()`, quando usado como um alvo de atribuição ou exclusão, respectivamente).

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

- Os métodos especiais `__oct__()` e `__hex__()` foram removidos – `oct()` e `hex()` usam `__index__()` agora para converter o argumento em um inteiro.

- Removido o suporte para `__members__` e `__methods__`.

- The function attributes named `func_X` have been renamed to use the `__X__` form, freeing up these names in the function attribute namespace for user-defined attributes. To wit, `func_closure`, `func_code`, `func_defaults`, `func_dict`, `func_doc`, `func_globals`, `func_name` were renamed to `__closure__`, `__code__`, `__defaults__`, `__dict__`, `__doc__`, `__globals__`, `__name__`, respectively.

- `__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()` foi renomeada para `input()`. Ou seja, a nova função `input()` lê uma linha de `sys.stdin` e a retorna com a nova linha final removida. Ela levanta `EOFError` se a entrada for encerrada prematuramente. Para obter o comportamento antigo de `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.

- Movida `intern()` para `sys.intern()`.

- Removida: `apply()`. Em vez de `apply(f, args)` use `f(*args)`.

- Removida `callable()`. Em vez de `callable(f)` você pode usar `isinstance(f, collections.Callable)`. A função `operator.isCallable()` também foi removida.

- Removida `coerce()`. Esta função não tem mais propósito agora que as classes clássicas desapareceram.

- Removida `execfile()`. Em vez de `execfile(fn)` use `exec(open(fn).read())`.

- Removido o tipo `file`. Use `open()`. Agora há vários tipos diferentes de fluxos que open pode retornar no módulo `io`.

- Removida `reduce()`. Use `functools.reduce()` se realmente precisar; no entanto, 99 por cento das vezes um laço explícito `for` é mais legível.

- Removed `reload()`. Use `imp.reload()`.

- Removida. `dict.has_key()` – use o operador `in` em vez disso.

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

- `PyNumber_Coerce()`, `PyNumber_CoerceEx()`, `PyMember_Get()`, and `PyMember_Set()` C APIs are removed.

- Nova API C `PyImport_ImportModuleNoBlock()`, funciona como `PyImport_ImportModule()`, mas não bloqueia na trava de importação (retornando um erro).

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

- Removed `METH_OLDARGS` and `WITH_CYCLE_GC` from the C API.

## 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:

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

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

2. (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.

3. Execute o tradutor de fonte para fonte `2to3` sobre sua árvore de código-fonte. (Veja 2to3 — Tradução Automatizada de Código Python 2 para 3 para mais informações sobre esta ferramenta.) Execute o resultado da tradução no Python 3.0. Corrija manualmente quaisquer problemas restantes, corrigindo os 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.