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

Autor:
   A.M. Kuchling (amk at amk.ca)

Este artigo explica os novos recursos do Python 2.7. O Python 2.7 foi
lançado em 3 de julho de 2010.

A manipulação numérica foi aprimorada de várias maneiras, tanto para
números de ponto flutuante quanto para a classe "Decimal". Existem
algumas adições úteis à biblioteca padrão, como um módulo "unittest"
bastante aprimorado, o módulo "argparse" para analisar as opções da
linha de comando, classes convenientes "OrderedDict" e "Counter" no
módulo "collections" e muitas outras melhorias.

O Python 2.7 está planejado para ser o último dos lançamentos 2.x, por
isso trabalhamos para torná-lo um bom lançamento a longo prazo. Para
ajudar na migração para o Python 3, vários novos recursos da série
Python 3.x foram incluídos no 2.7.

Este artigo não tenta fornecer uma especificação completa dos novos
recursos, mas fornece uma visão geral conveniente. Para detalhes
completos, você deve consultar a documentação do Python 2.7 em
https://docs.python.org. Se você deseja entender a lógica do design e
implementação, consulte a PEP para obter um novo recurso específico ou
o problema em https://bugs.python.org no qual uma alteração foi
discutida. Sempre que possível, o "O que há de novo no Python" é
vinculado ao item de bug/patch de cada alteração.


O futuro para o Python 2.x
==========================

Python 2.7 é o último grande lançamento da série 2.x, já que os
mantenedores do Python mudaram o foco de seus esforços de
desenvolvimento de novos recursos para a série Python 3.x. Isso
significa que, embora o Python 2 continue recebendo correções de bugs
e seja atualizado para construir corretamente em novo hardware e
versões de sistemas operados com suporte, não haverá novos lançamentos
de recursos completos para a linguagem ou biblioteca padrão.

No entanto, embora haja um grande subconjunto comum entre Python 2.7 e
Python 3, e muitas das mudanças envolvidas na migração para esse
subconjunto comum, ou diretamente para Python 3, podem ser
automatizadas com segurança, algumas outras mudanças (principalmente
aquelas associadas ao tratamento Unicode) pode exigir uma consideração
cuidadosa e, de preferência, conjuntos de testes de regressão
automatizados robustos, para migrar com eficácia.

Isso significa que o Python 2.7 permanecerá em vigor por um longo
tempo, fornecendo uma plataforma base estável e com suporte para
sistemas de produção que ainda não foram portados para Python 3. O
ciclo de vida completo esperado da série Python 2.7 é detalhado na
**PEP 373**.

Algumas consequências principais da significância de longo prazo de
2.7 são:

* Conforme observado acima, a versão 2.7 tem um período de manutenção
  muito mais longo em comparação com as versões 2.x anteriores.
  Atualmente, espera-se que o Python 2.7 continue com o suporte da
  equipe de desenvolvimento central (recebendo atualizações de
  segurança e outras correções de bugs) até pelo menos 2020 (10 anos
  após seu lançamento inicial, em comparação com o período de suporte
  mais típico de 18-24 meses).

* Conforme a biblioteca padrão do Python 2.7 envelhece, fazer uso
  efetivo do Python Package Index (diretamente ou por meio de um
  redistribuidor) torna-se mais importante para os usuários do Python
  2. Além de uma grande variedade de pacotes de terceiros para várias
  tarefas, os pacotes disponíveis incluem backports de novos módulos e
  recursos da biblioteca padrão do Python 3 que são compatíveis com o
  Python 2, bem como várias ferramentas e bibliotecas que podem tornar
  mais fácil migre para Python 3. O Guia de Usuário para Empacotamento
  de Python fornece orientação sobre como baixar e instalar software
  do Python Package Index.

* Embora a abordagem preferida para aprimorar o Python 2 agora seja a
  publicação de novos pacotes no Python Package Index, essa abordagem
  não funciona necessariamente em todos os casos, especialmente
  aqueles relacionados à segurança de rede. Em casos excepcionais que
  não podem ser tratados adequadamente com a publicação de pacotes
  novos ou atualizados no PyPI, o processo de Proposta de Melhoria do
  Python, ou PEP, pode ser usado para justificar a adição de novos
  recursos diretamente à biblioteca padrão do Python 2. Quaisquer
  adições, e as versões de manutenção onde foram adicionadas, serão
  observadas na seção Novos recursos adicionados às versões de
  manutenção do Python 2.7 abaixo.

Para projetos que desejam migrar de Python 2 para Python 3, ou para
desenvolvedores de bibliotecas e frameworks que desejam oferecer
suporte a usuários em Python 2 e Python 3, há uma variedade de
ferramentas e guias disponíveis para ajudar a decidir sobre uma
abordagem adequada e gerenciar alguns dos os detalhes técnicos
envolvidos. O ponto de partida recomendado é o guia Como portar
códigos do Python 2 para o Python 3.


Mudanças no tratamento de avisos de descontinuação
==================================================

Para Python 2.7, uma decisão política foi feita para silenciar avisos
apenas de interesse para desenvolvedores por padrão.
"DeprecationWarning" e seus descendentes agora são ignorados a menos
que solicitado de outra forma, evitando que os usuários vejam avisos
acionados por uma aplicação. Essa mudança também foi feita no branch
que se tornou o Python 3.2. (Discutido em stdlib-sig e realizado em
bpo-7319.)

Em versões anteriores, as mensagens "DeprecationWarning" eram
habilitadas por padrão, fornecendo aos desenvolvedores de Python uma
indicação clara de onde seu código pode quebrar em uma versão
principal futura do Python.

No entanto, há cada vez mais usuários de aplicações baseadas em Python
que não estão diretamente envolvidos no desenvolvimento dessas
aplicações. Mensagens de "DeprecationWarning" são irrelevantes para
tais usuários, fazendo-os se preocupar com uma aplicação que está
realmente funcionando corretamente e sobrecarregando os
desenvolvedores de aplicações com a resposta a essas preocupações.

Você pode reativar a exibição de mensagens "DeprecationWarning"
executando Python com a opção "-Wdefault" (forma curta: "-Wd") ou
definindo a variável de ambiente "PYTHONWARNINGS" para ""default"" (ou
""d"") antes de executar o Python. O código Python também pode
reativá-los chamando "warnings.simplefilter('default')".

O módulo "unittest" também reativa automaticamente os avisos de
depreciação ao executar testes.


Recursos do Python 3.1
======================

Assim como o Python 2.6 incorporou recursos do Python 3.0, a versão
2.7 incorpora alguns dos novos recursos do Python 3.1. A série 2.x
continua a fornecer ferramentas para migração para a série 3.x.

Uma lista parcial de recursos do 3.1 que foram transferidos para o
2.7:

* A sintaxe para conjuntos de literais ("{1,2,3}" é um conjunto
  mutável).

* Compreensões de dicionário e conjunto ("{i: i*2 for i in
  range(3)}").

* Vários gerenciadores de contexto em uma única instrução "with".

* Uma nova versão da biblioteca "io", reescrita em C para melhor
  desempenho.

* O tipo de dicionário ordenado descrito na PEP 372: Adicionando um
  dicionário ordenado a coleções.

* O novo especificador de formato "","" descrito na PEP 378:
  Especificador de formato para separador de milhares.

* O objeto "memoryview".

* Um pequeno subconjunto do módulo "importlib", descrito sob.

* O "repr()" de um ponto flutuante "x" é mais curto em muitos casos:
  agora é baseado na string decimal mais curta que é garantida para
  arredondar de volta para "x". Como nas versões anteriores do Python,
  é garantido que "float(repr(x))" recupera "x".

* As conversões de ponto flutuante para string e string para ponto
  flutuante são arredondadas corretamente. A função "round()" também
  está agora corretamente arredondada.

* O tipo "PyCapsule", usado para fornecer uma API C para módulos de
  extensão.

* A função de API C "PyLong_AsLongAndOverflow()".

Outros novos avisos do modo Python3 incluem:

* "operator.isCallable()" e "operator.sequenceIncludes()", que não são
  suportados no 3.x, agora disparam avisos.

* A opção "-3" agora habilita automaticamente a opção "-Qwarn" que
  causa avisos sobre o uso de divisão clássica com inteiros e inteiros
  longos.


PEP 372: Adicionando um dicionário ordenado a coleções
======================================================

Dicionários regulares no Python iteram sobre pares de chave/valor em
ordem arbitrária. Ao longo dos anos, vários autores escreveram
implementações alternativas que lembram a ordem em que as chaves foram
inseridas originalmente. Com base nas experiências dessas
implementações, 2.7 introduz uma nova classe "OrderedDict" no módulo
"collections".

A API "OrderedDict" fornece a mesma interface que os dicionários
regulares, mas itera sobre chaves e valores em uma ordem garantida
dependendo de quando uma chave foi inserida pela primeira vez:

   >>> from collections import OrderedDict
   >>> d = OrderedDict([('first', 1),
   ...                  ('second', 2),
   ...                  ('third', 3)])
   >>> d.items()
   [('first', 1), ('second', 2), ('third', 3)]

Se uma nova entrada substituir uma entrada existente, a posição de
inserção original permanece inalterada:

   >>> d['second'] = 4
   >>> d.items()
   [('first', 1), ('second', 4), ('third', 3)]

Excluir uma entrada e reinseri-la irá movê-la para o final:

   >>> del d['second']
   >>> d['second'] = 5
   >>> d.items()
   [('first', 1), ('third', 3), ('second', 5)]

O método "popitem()" tem um argumento opcional *last* cujo valor
padrão é "True". Se *last* for true, a chave adicionada mais
recentemente é retornada e removida; se for falso, a chave mais antiga
é selecionada:

   >>> od = OrderedDict([(x,0) for x in range(20)])
   >>> od.popitem()
   (19, 0)
   >>> od.popitem()
   (18, 0)
   >>> od.popitem(last=False)
   (0, 0)
   >>> od.popitem(last=False)
   (1, 0)

A comparação de dois dicionários ordenados verifica as chaves e os
valores e exige que o pedido de inserção seja o mesmo:

   >>> od1 = OrderedDict([('first', 1),
   ...                    ('second', 2),
   ...                    ('third', 3)])
   >>> od2 = OrderedDict([('third', 3),
   ...                    ('first', 1),
   ...                    ('second', 2)])
   >>> od1 == od2
   False
   >>> # Move a chave 'third' para o fim
   >>> del od2['third']; od2['third'] = 3
   >>> od1 == od2
   True

Comparar um "OrderedDict" com um dicionário regular ignora a ordem de
inserção e apenas compara as chaves e valores.

Como funciona a "OrderedDict"? Ela mantém uma lista duplamente
vinculada de chaves, acrescentando novas chaves à lista à medida que
são inseridas. Um dicionário secundário mapeia as chaves para seu nó
de lista correspondente, portanto, a exclusão não precisa percorrer
toda a lista vinculada e, portanto, permanece *O*(1).

A biblioteca padrão agora oferece suporte ao uso de dicionários
ordenados em vários módulos.

* O módulo "ConfigParser" os usa por padrão, o que significa que os
  arquivos de configuração agora podem ser lidos, modificados e então
  escritos de volta em sua ordem original.

* O método "_asdict()" para "collections.namedtuple()" agora retorna
  um dicionário ordenado com os valores aparecendo na mesma ordem que
  os índices de tupla subjacentes.

* O construtor de classe "JSONDecoder" do módulo "json" foi estendido
  com um parâmetro *object_pairs_hook* para permitir que instâncias
  "OrderedDict" sejam construídas pelo decodificador. O suporte também
  foi adicionado para ferramentas de terceiros como PyYAML.

Ver também:

  **PEP 372** - Adicionando um dicionário ordenado às coleções
     PEP escrita por Armin Ronacher e Raymond Hettinger; implementada
     por Raymond Hettinger.


PEP 378: Especificador de formato para separador de milhares
============================================================

Para tornar a saída do programa mais legível, pode ser útil adicionar
separadores a números grandes, renderizando-os como
18,446,744.073,709,551,616 em vez de 18446744073709551616.

A solução totalmente geral para fazer isso é o módulo "locale", que
pode usar diferentes separadores ("," na América do Norte, "." na
Europa) e diferentes tamanhos de agrupamento, mas "locale" é
complicado para usar e inadequado para aplicativos multithread onde
diferentes threads estão produzindo saída para diferentes localidades.

Portanto, um mecanismo simples de agrupamento de vírgulas foi
adicionado à minilinguagem usada pelo método "str.format()". Ao
formatar um número de ponto flutuante, basta incluir uma vírgula entre
a largura e a precisão:

   >>> '{:20,.2f}'.format(18446744073709551616.0)
   '18,446,744,073,709,551,616.00'

Ao formatar um número inteiro, inclua a vírgula após a largura:

>>> '{:20,d}'.format(18446744073709551616)
'18,446,744,073,709,551,616'

Este mecanismo não é adaptável de forma alguma; vírgulas são sempre
usadas como separadores e o agrupamento é sempre em grupos de três
dígitos. O mecanismo de formatação de vírgula não é tão geral quanto o
módulo "locale", mas é mais fácil de usar.

Ver também:

  **PEP 378** - Especificador de formato para separador de milhares
     PEP escrita por Raymond Hettinger; implementada por Eric Smith.


PEP 389: O módulo argparse para analisar linhas de comando
==========================================================

O módulo "argparse" para analisar argumentos de linha de comando foi
adicionado como um substituto mais poderoso para o módulo "optparse".

Isso significa que Python agora oferece suporte a três módulos
diferentes para analisar argumentos de linha de comando: "getopt",
"optparse" e "argparse". O módulo "getopt" se assemelha muito à função
"getopt()" da biblioteca C, portanto continua útil se você estiver
escrevendo um protótipo Python que eventualmente será reescrito em C.
"optparse" torna-se redundante, mas não há planos para removê-lo
porque muitos scripts ainda o utilizam e não há uma maneira
automatizada de atualizar esses scripts. (Tornar a API "argparse"
consistente com a interface de "optparse" foi discutido, mas rejeitado
por ser muito confuso e difícil.)

Resumindo, se você está escrevendo um novo script e não precisa se
preocupar com a compatibilidade com versões anteriores do Python, use
"argparse" ao invés de "optparse".

Aqui está um exemplo:

   import argparse

   parser = argparse.ArgumentParser(description='Command-line example.')

   # Adiciona alterações opcionais
   parser.add_argument('-v', action='store_true', dest='is_verbose',
                       help='produce verbose output')
   parser.add_argument('-o', action='store', dest='output',
                       metavar='FILE',
                       help='direct output to FILE instead of stdout')
   parser.add_argument('-C', action='store', type=int, dest='context',
                       metavar='NUM', default=0,
                       help='display NUM lines of added context')

   # Permite qualquer número de argumentos adicionais.
   parser.add_argument(nargs='*', action='store', dest='inputs',
                       help='input filenames (default is stdin)')

   args = parser.parse_args()
   print args.__dict__

A menos que você o substitua, as opções "-h" e "--help" são
adicionadas automaticamente e produzem uma saída formatada de maneira
organizada:

   -> ./python.exe argparse-example.py --help
   usage: argparse-example.py [-h] [-v] [-o FILE] [-C NUM] [inputs [inputs ...]]

   Command-line example.

   positional arguments:
     inputs      input filenames (default is stdin)

   optional arguments:
     -h, --help  show this help message and exit
     -v          produce verbose output
     -o FILE     direct output to FILE instead of stdout
     -C NUM      display NUM lines of added context

Como em "optparse", as opções e argumentos da linha de comando são
retornados como um objeto com atributos nomeados pelos parâmetros
*dest*:

   -> ./python.exe argparse-example.py -v
   {'output': None,
    'is_verbose': True,
    'context': 0,
    'inputs': []}

   -> ./python.exe argparse-example.py -v -o /tmp/output -C 4 file1 file2
   {'output': '/tmp/output',
    'is_verbose': True,
    'context': 4,
    'inputs': ['file1', 'file2']}

"argparse" tem uma validação muito mais sofisticada que "optparse";
você pode especificar um número exato de argumentos como um inteiro, 0
ou mais argumentos passando "'*'", 1 ou mais passando "'+'", ou um
argumento opcional com "'?'". Um analisador de nível superior pode
conter sub-analisadores para definir subcomandos que possuem
diferentes conjuntos de opções, como em "svn commit", "svn checkout",
etc. Você pode especificar o tipo de um argumento como "FileType", que
abrirá arquivos automaticamente para você e entende que "'-'"
significa entrada ou saída padrão.

Ver também:

  Documentação do "argparse"
     A página de documentação do módulo argparse.

  Migrando código optparse para argparse
     Parte da documentação do Python, descrevendo como converter o
     código que usa "optparse".

  **PEP 389** - argparse - Novo módulo de análise sintática de linha
  de comando
     PEP escrita e implementada por Steven Bethard.


PEP 391: Configuração baseada em dicionário para logging
========================================================

O módulo "logging" é muito flexível; os aplicativos podem definir uma
árvore de subsistemas de log e cada logger nessa árvore pode filtrar
determinadas mensagens, formatá-las de maneira diferente e direcionar
mensagens para um número variável de manipuladores.

Toda essa flexibilidade pode exigir muita configuração. Você pode
escrever instruções Python para criar objetos e definir suas
propriedades, mas uma configuração complexa requer um código
detalhado, mas enfadonho. "logging" também suporta uma função
"fileConfig()" que analisa um arquivo, mas o formato do arquivo não
oferece suporte  à configuração de filtros, e é mais confuso gerar
programaticamente.

O Python 2.7 adiciona uma função "dictConfig()" que usa um dicionário
para configurar o log. Existem muitas maneiras de produzir um
dicionário a partir de diferentes fontes: construir um com código;
analisar um arquivo contendo JSON; ou use uma biblioteca de análise de
YAML se houver uma instalada. Para mais informações veja Funções de
configuração.

O exemplo a seguir configura dois loggers, o logger raiz e um logger
denominado "network". As mensagens enviadas para o registrador raiz
serão enviadas para o log do sistema usando o protocolo syslog, e as
mensagens para o logger "network" serão gravadas em um arquivo
"network.log" que será rotacionado assim que o log atingir 1 MB.

   import logging
   import logging.config

   configdict = {
    'version': 1,    # Configuration schema in use; must be 1 for now
    'formatters': {
        'standard': {
            'format': ('%(asctime)s %(name)-15s '
                       '%(levelname)-8s %(message)s')}},

    'handlers': {'netlog': {'backupCount': 10,
                        'class': 'logging.handlers.RotatingFileHandler',
                        'filename': '/logs/network.log',
                        'formatter': 'standard',
                        'level': 'INFO',
                        'maxBytes': 1000000},
                 'syslog': {'class': 'logging.handlers.SysLogHandler',
                            'formatter': 'standard',
                            'level': 'ERROR'}},

    # Especifica todos os loggers subordinados
    'loggers': {
                'network': {
                            'handlers': ['netlog']
                }
    },
    # Especifica propriedades do logger raiz
    'root': {
             'handlers': ['syslog']
    },
   }

   # Prepara as configurações
   logging.config.dictConfig(configdict)

   # Como um exemplo, registra duas mensagens de erro
   logger = logging.getLogger('/')
   logger.error('Database not found')

   netlogger = logging.getLogger('network')
   netlogger.error('Connection failed')

Três melhorias menores no módulo "logging", todas implementadas por
Vinay Sajip, são:

* A classe "SysLogHandler" agora tem suporte a syslogging sobre TCP. O
  construtor tem um parâmetro *socktype* que fornece o tipo de soquete
  a ser usado, "socket.SOCK_DGRAM" para UDP ou "socket.SOCK_STREAM"
  para TCP. O protocolo padrão permanece UDP.

* As instâncias "Logger" ganharam um método "getChild()" que recupera
  um logger descendente usando um caminho relativo. Por exemplo,
  depois de recuperar um logger fazendo "log = getLogger('app')",
  chamar "log.getChild('network.listen')" é equivalente a
  "getLogger('app.network.listen')".

* A classe "LoggerAdapter" ganhou um método "isEnabledFor()" que pega
  um *level* e retorna se o logger subjacente processaria uma mensagem
  desse nível de importância.

Ver também:

  **PEP 391** - Configuração baseada em dicionário para logging
     PEP escrita e implementada por Vinay Sajip.


PEP 3106: Views de dicionário
=============================

Os métodos de dicionário "keys()", "values()" e "items()" são
diferentes no Python 3.x. Eles retornam um objeto chamado *view* em
vez de uma lista totalmente materializada.

Não é possível alterar os valores de retorno de "keys()", "values()" e
"items()" no Python 2.7 porque muito código seria interrompido. Em vez
disso, as versões 3.x foram adicionadas com os novos nomes
"viewkeys()", "viewvalues()" e "viewitems()".

   >>> d = dict((i*10, chr(65+i)) for i in range(26))
   >>> d
   {0: 'A', 130: 'N', 10: 'B', 140: 'O', 20: ..., 250: 'Z'}
   >>> d.viewkeys()
   dict_keys([0, 130, 10, 140, 20, 150, 30, ..., 250])

As views podem ser iteradas, mas as exibições de chave e item também
se comportam como conjuntos. O operador "&" realiza a interseção, e o
"|" realiza uma união:

   >>> d1 = dict((i*10, chr(65+i)) for i in range(26))
   >>> d2 = dict((i**.5, i) for i in range(1000))
   >>> d1.viewkeys() & d2.viewkeys()
   set([0.0, 10.0, 20.0, 30.0])
   >>> d1.viewkeys() | range(0, 30)
   set([0, 1, 130, 3, 4, 5, 6, ..., 120, 250])

A view acompanha o dicionário e seu conteúdo muda à medida que o
dicionário é modificado:

   >>> vk = d.viewkeys()
   >>> vk
   dict_keys([0, 130, 10, ..., 250])
   >>> d[260] = '&'
   >>> vk
   dict_keys([0, 130, 260, 10, ..., 250])

No entanto, observe que você não pode adicionar ou remover chaves
enquanto estiver iterando na view:

   >>> for k in vk:
   ...     d[k*2] = k
   ...
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   RuntimeError: dictionary changed size during iteration

Você pode usar os métodos de exibição no código Python 2.x, e o
conversor 2to3 irá alterá-los para os métodos padrão "keys()",
"values()" e "items()".

Ver também:

  **PEP 3106** - Repaginação de dict.keys(), .values() e .items()
     PEP escrita por Guido van Rossum. Backported para 2.7 por
     Alexandre Vassalotti; bpo-1967.


PEP 3137: O objeto memoryview
=============================

O objeto "memoryview" fornece uma visão do conteúdo da memória de
outro objeto que corresponde à interface do tipo "bytes".

   >>> import string
   >>> m = memoryview(string.letters)
   >>> m
   <memory at 0x37f850>
   >>> len(m)           # Retorna o comprimento de objeto subjacente
   52
   >>> m[0], m[25], m[26]   # Indexação retorna um byte
   ('a', 'z', 'A')
   >>> m2 = m[0:26]         # Fatiamento retorna outra memoryview
   >>> m2
   <memory at 0x37f080>

O conteúdo da viewq pode ser convertido em uma string de bytes ou uma
lista de inteiros:

   >>> m2.tobytes()
   'abcdefghijklmnopqrstuvwxyz'
   >>> m2.tolist()
   [97, 98, 99, 100, 101, 102, 103, ... 121, 122]
   >>>

Objetos "memoryview" permitem modificar o objeto subjacente se for um
objeto mutável.

   >>> m2[0] = 75
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   TypeError: cannot modify read-only memory
   >>> b = bytearray(string.letters)  # Criando um objeto mutável
   >>> b
   bytearray(b'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ')
   >>> mb = memoryview(b)
   >>> mb[0] = '*'         # Atribui para visão, alterando o bytearray.
   >>> b[0:5]              # O bytearray foi alterado.
   bytearray(b'*bcde')
   >>>

Ver também:

  **PEP 3137** - Bytes imutáveis e buffer mutável
     PEP escrita por Guido van Rossum. Implementada por Travis
     Oliphant, Antoine Pitrou e outros. Portado para 2.7 por Antoine
     Pitrou; bpo-2396.


Outras mudanças na linguagem
============================

Algumas das mudanças menores feitas no núcleo da linguagem Python são:

* A sintaxe para set literais foi portada do Python 3.x. Os colchetes
  são usados para cercar o conteúdo do conjunto mutável resultante; os
  literais definidos são diferenciados dos dicionários por não
  conterem caracteres de dois pontos e valores. "{}" continua a
  representar um dicionário vazio; use "set()" para um conjunto vazio.

     >>> {1, 2, 3, 4, 5}
     set([1, 2, 3, 4, 5])
     >>> set() # conjunto vazio
     set([])
     >>> {}    # dicionário vazio
     {}

  Portado por Alexandre Vassalotti; bpo-2335.

* As compreensões de dicionário e conjunto são outro recurso importado
  do 3.x, generalizando as compreensões de lista/gerador para usar a
  sintaxe literal para conjuntos e dicionários.

     >>> {x: x*x for x in range(6)}
     {0: 0, 1: 1, 2: 4, 3: 9, 4: 16, 5: 25}
     >>> {('a'*x) for x in range(6)}
     set(['', 'a', 'aa', 'aaa', 'aaaa', 'aaaaa'])

  Portado por Alexandre Vassalotti; bpo-2333.

* A instrução "with" agora pode usar vários gerenciadores de contexto
  em uma instrução. Os gerenciadores de contexto são processados da
  esquerda para a direita e cada um é tratado como o início de uma
  nova instrução "with". Isso significa que:

     with A() as a, B() as b:
         ... conjunto de instruções ...

  é equivalente a:

     with A() as a:
         with B() as b:
             ... conjunto de instruções ...

  A função "contextlib.nested()" fornece uma função muito similar,
  então não é mais necessária e foi descontinuada.

  (Proposta em https://codereview.appspot.com/53094; implementada por
  Georg Brandl.)

* As conversões entre números de ponto flutuante, ou float. e strings
  agora são arredondadas corretamente na maioria das plataformas.
  Estas conversões ocorrem em muitos lugares diferentes: "str()" em
  floats e números complexos; os construtores "float" e "complex";
  formatação numérica; serializar e desserializar floats e números
  complexos usando os módulos "marshal", "pickle" e "json"; análise de
  float e literais imaginários no código Python; e a conversão
  "Decimal"-para-float.

  Relacionado a isso, o "repr()" de um número de ponto flutuante *x*
  agora retorna um resultado baseado na string decimal mais curta que
  é garantida para arredondar de volta para *x* sob o arredondamento
  correto (com o modo de arredondamento round-half-to-even).
  Anteriormente, fornecia uma string baseada no arredondamento x para
  17 dígitos decimais.

  A biblioteca de arredondamento responsável por essa melhoria
  funciona no Windows e em plataformas Unix usando os compiladores
  gcc, icc ou suncc. Pode haver um pequeno número de plataformas onde
  a operação correta deste código não pode ser garantida, então o
  código não é usado em tais sistemas. Você pode descobrir qual código
  está sendo usado verificando "sys.float_repr_style", que será
  "short" se o novo código estiver em uso e "legacy" se não estiver.

  Implementada por Eric Smith and Mark Dickinson, usando a biblioteca
  "dtoa.c" de David Gay; bpo-7117.

* As conversões de inteiros longos e inteiros regulares para ponto
  flutuante agora arredondam de maneira diferente, retornando o número
  de ponto flutuante mais próximo ao número. Isso não importa para
  pequenos inteiros que podem ser convertidos exatamente, mas para
  grandes números que inevitavelmente perderão a precisão, o Python
  2.7 agora se aproxima mais. Por exemplo, o Python 2.6 computou o
  seguinte:

     >>> n = 295147905179352891391
     >>> float(n)
     2.9514790517935283e+20
     >>> n - long(float(n))
     65535L

  O resultado de ponto flutuante do Python 2.7 é maior, mas muito mais
  próximo do valor verdadeiro:

     >>> n = 295147905179352891391
     >>> float(n)
     2.9514790517935289e+20
     >>> n - long(float(n))
     -1L

  (Implementada por Mark Dickinson; bpo-3166.)

  A divisão inteira também é mais precisa em seus comportamentos de
  arredondamento. (Também implementada por Mark Dickinson; bpo-1811.)

* A coerção implícita para números complexos foi removida; o
  interpretador nunca mais tentará chamar um método "__coerce__()" em
  objetos complexos. (Removido por Meador Inge e Mark Dickinson;
  bpo-5211.)

* O método "str.format()" agora tem suporte à numeração automática dos
  campos de substituição. Isso torna o uso de "str.format()" mais
  parecido com o uso da formatação "%s":

     >>> '{}:{}:{}'.format(2009, 04, 'Sunday')
     '2009:4:Sunday'
     >>> '{}:{}:{day}'.format(2009, 4, day='Sunday')
     '2009:4:Sunday'

  A numeração automática leva os campos da esquerda para a direita,
  então o primeiro especificador "{...}" usará o primeiro argumento
  para "str.format()", o próximo especificador usará o próximo
  argumento e breve. Você não pode misturar a numeração automática e a
  numeração explícita -- numerar todos os seus campos especificadores
  ou nenhum deles -- mas você pode misturar a numeração automática e
  os campos nomeados, como no segundo exemplo acima. (Contribuição de
  Eric Smith; bpo-5237.)

  Números complexos agora suportam corretamente o uso com "format()",
  e o padrão é alinhamento à direita. A especificação de uma precisão
  ou separação por vírgula aplica-se às partes reais e imaginárias do
  número, mas uma largura de campo e alinhamento especificados são
  aplicados a toda a saída "1.5+3j" resultante. (Contribuição de Eric
  Smith; bpo-1588 e bpo-7988.)

  O código de formato 'F' agora sempre formata sua saída usando
  caracteres maiúsculos, então agora produzirá 'INF' e 'NAN'.
  (Contribuição de Eric Smith; bpo-3382.)

  Uma alteração de baixo nível: o método "object.__format__()" agora
  aciona um "PendingDeprecationWarning" se for passado uma string de
  formato, porque o método "__format__()" para "object" converte o
  objeto para uma representação de string e formata isso.
  Anteriormente, o método aplicava silenciosamente a string de formato
  à representação da string, mas isso poderia ocultar erros no código
  Python. Se você estiver fornecendo informações de formatação, como
  alinhamento ou precisão, presumivelmente espera que a formatação
  seja aplicada de alguma maneira específica do objeto. (Correção de
  Eric Smith; bpo-7994.)

* Os tipos "int()" e "long()" ganharam um método "bit_length" que
  retorna o número de bits necessários para representar seu argumento
  em binário:

     >>> n = 37
     >>> bin(n)
     '0b100101'
     >>> n.bit_length()
     6
     >>> n = 2**123-1
     >>> n.bit_length()
     123
     >>> (n+1).bit_length()
     124

  (Contribuição de Fredrik Johansson e Victor Stinner; bpo-3439.)

* A instrução "import" não tentará mais uma importação absoluta se uma
  importação relativa (por exemplo, "from .os import sep") falhar.
  Isso corrige um bug, mas pode possivelmente quebrar certas
  instruções "import" que estavam funcionando apenas por acidente.
  (Correção de Meador Inge; bpo-7902.)

* Agora é possível para uma subclasse do tipo embutido "unicode"
  substituir o método "__unicode__()". (Implementado por Victor
  Stinner; bpo-1583863.)

* O método "translate()" do tipo "bytearray" agora aceita "None" como
  seu primeiro argumento. (Correção de Georg Brandl; bpo-4759.)

* Ao usar "@classmethod" e "@staticmethod" para agrupar métodos como
  classe ou métodos estáticos, o objeto envólucro agora expõe a função
  agrupada como seu atributo "__func__". (Contribuição de Amaury
  Forgeot d'Arc, após sugestão de George Sakkis; bpo-5982.)

* Quando um conjunto restrito de atributos foi definido usando
  "__slots__", excluir um atributo não definido não levantaria
  "AttributeError" como seria de esperar. Correção de Benjamin
  Peterson; bpo-7604.)

* Duas novas codificações agora são suportadas: "cp720", usado
  principalmente para texto em árabe; e "cp858", uma variante do CP
  850 que adiciona o símbolo do euro. (CP720 foi contribuição de
  Alexander Belchenko e Amaury Forgeot d'Arc em bpo-1616979; CP858 foi
  contribuição de Tim Hatch em bpo-8016.)

* O objeto "file" agora definirá o atributo "filename" na exceção
  "IOError" ao tentar abrir um diretório em plataformas POSIX
  (observado por Jan Kaliszewski; bpo-4764) , e agora verifica
  explicitamente e proíbe a gravação em objetos arquivo somente
  leitura em vez de confiar na biblioteca C para detectar e relatar o
  erro (correção de Stefan Krah; bpo-5677).

* O tokenizador do Python agora traduz as próprias terminações de
  linha, então a função embutida "compile()" agora aceita código
  usando qualquer convenção de terminação de linha. Além disso, não
  requer mais que o código termine em uma nova linha.

* Parênteses extras em definições de função são ilegais no Python 3.x,
  o que significa que você obtém um erro de sintaxe de "def f((x)):
  pass". No modo de aviso do Python3, o Python 2.7 agora avisará sobre
  esse uso estranho. (Notado por James Lingard; bpo-7362.)

* Agora é possível criar referências fracas para objetos de classe de
  estilo antigo. As classes de novo estilo sempre tiveram referências
  fracas. (Correção de Antoine Pitrou; bpo-8268.)

* Quando um objeto de módulo é coletado como lixo, o dicionário do
  módulo agora só é limpo se ninguém mais estiver mantendo uma
  referência ao dicionário (bpo-7140).


Alterações no interpretador
---------------------------

Uma nova variável de ambiente, "PYTHONWARNINGS", permite controlar os
avisos. Deve ser definido como uma string contendo configurações de
aviso, equivalentes àquelas usadas com a opção "-W", separadas por
vírgulas. (Contribuição de Brian Curtin; bpo-7301.)

Por exemplo, a configuração a seguir imprimirá avisos toda vez que
ocorrerem, mas transformará os avisos do módulo "Cookie" em um erro.
(A sintaxe exata para definir uma variável de ambiente varia entre
sistemas operacionais e shells.)

   export PYTHONWARNINGS=all,error:::Cookie:0


Otimizações
-----------

Vários aprimoramentos de desempenho foram adicionados:

* Um novo opcode foi adicionado para executar a configuração inicial
  das instruções "with", procurando os métodos "__enter__()" e
  "__exit__()". (Contribuição de Benjamin Peterson.)

* O coletor de lixo agora funciona melhor para um padrão de uso comum:
  quando muitos objetos estão sendo alocados sem desalocar nenhum
  deles. Anteriormente, isso levaria um tempo quadrático para coleta
  de lixo, mas agora o número de coletas de lixo completas é reduzido
  à medida que o número de objetos no heap aumenta. A nova lógica só
  executa uma passagem completa de coleta de lixo quando a geração
  intermediária tiver sido coletada 10 vezes e quando o número de
  objetos sobreviventes da geração intermediária exceder 10% do número
  de objetos da geração mais antiga. (Sugerido por Martin von Löwis e
  implementado por Antoine Pitrou; bpo-4074.)

* O coletor de lixo tenta evitar o rastreamento de contêineres simples
  que não podem fazer parte de um ciclo. No Python 2.7, isso agora é
  verdade para tuplas e dicts contendo tipos atômicos (como ints,
  strings, etc.). Transitivamente, um dict contendo tuplas de tipos
  atômicos também não será rastreado. Isso ajuda a reduzir o custo de
  cada coleta de lixo diminuindo o número de objetos a serem
  considerados e percorridos pelo coletor. (Contribuição de Antoine
  Pitrou; bpo-4688.)

* Inteiros longos agora são armazenados internamente na base "2**15"
  ou na base "2**30", sendo a base determinada no momento da
  compilação. Anteriormente, eles eram sempre armazenados na base
  "2**15". O uso de base "2**30" oferece melhorias significativas de
  desempenho em máquinas de 64 bits, mas os resultados de benchmark em
  máquinas de 32 bits foram mistos. Portanto, o padrão é usar base
  "2**30" em máquinas de 64 bits e base "2**15" em máquinas de 32
  bits; no Unix, há uma nova opção de configuração "--enable-big-
  digits" que pode ser usada para substituir esse padrão.

  Além das melhorias de desempenho, essa alteração deve ser invisível
  para os usuários finais, com uma exceção: para fins de teste e
  depuração, há um novo structseq "sys.long_info" que fornece
  informações sobre o formato interno, fornecendo o número de bits por
  dígito e o tamanho em bytes do tipo C usado para armazenar cada
  dígito:

     >>> import sys
     >>> sys.long_info
     sys.long_info(bits_per_digit=30, sizeof_digit=4)

  (Contribuição de Mark Dickinson; bpo-4258.)

  Outro conjunto de alterações tornou os objetos longos alguns bytes
  menores: 2 bytes menores em sistemas de 32 bits e 6 bytes em
  sistemas de 64 bits. (Contribuição de Mark Dickinson; bpo-5260.)

* O algoritmo de divisão para números inteiros longos ficou mais
  rápido apertando o laço interno, fazendo deslocamentos em vez de
  multiplicações e corrigindo uma iteração extra desnecessária. Vários
  benchmarks mostram acelerações entre 50% e 150% para divisões
  inteiras longas e operações de módulo. (Contribuição de Mark
  Dickinson; bpo-5512.) Operações bit a bit também são
  significativamente mais rápidas (patch inicial de Gregory Smith;
  bpo-1087418).

* A implementação de "%" verifica se o operando do lado esquerdo é uma
  string Python e usa casos especiais; isso resulta em um aumento de
  desempenho de 1 a 3% para aplicativos que usam frequentemente "%"
  com strings, como templates em bibliotecas. (Implementação de Collin
  Winter; bpo-5176.)

* Compreensões de lista com uma condição "if" são compiladas em
  bytecode mais rápido. (Patch de Antoine Pitrou, retroportado para
  2.7 por Jeffrey Yasskin; bpo-4715.)

* A conversão de um inteiro ou inteiro longo em uma string decimal
  ficou mais rápida com o uso de maiúsculas e minúsculas especiais na
  base 10, em vez de usar uma função de conversão generalizada que
  oferece suporte a bases arbitrárias. (Patch por Gawain Bolton;
  bpo-6713.)

* Os métodos "split()", "replace()", "rindex()", "rpartition()" e
  "rsplit()" de tipos semelhantes a strings (strings, Strings Unicode
  e objetos "bytearray") agora usam um algoritmo de pesquisa reversa
  rápida em vez de uma varredura caractere por caractere. Às vezes,
  isso é mais rápido por um fator de 10. (Adicionado por Florent
  Xicluna; bpo-7462 e bpo-7622.)

* Os módulos "pickle" e "cPickle" agora internalizam automaticamente
  as strings usadas para nomes de atributos, reduzindo o uso de
  memória dos objetos resultantes da desserialização com pickle.
  (Contribuição de Jake McGuire; bpo-5084.)

* O módulo "cPickle" agora usa dicionários de casos especiais,
  reduzindo quase pela metade o tempo necessário para serializá-los
  com pickle. (Contribuição de Collin Winter; bpo-5670.)


Módulos Novos ou Aprimorados
============================

Como em todas os lançamentos, a biblioteca padrão do Python recebeu
diversas melhorias e correções de bugs. Aqui está uma lista parcial
das mudanças mais notáveis, classificadas em ordem alfabética por nome
do módulo. Consulte o arquivo "Misc/NEWS" na árvore de código-fonte
para uma lista mais completa de alterações, ou procure nos logs do
Subversion para todos os detalhes.

* A classe de depuração base do módulo "bdb" "Bdb" ganhou um recurso
  para pular módulos. O construtor agora usa um iterável contendo
  padrões estilo glob como "django.*"; o depurador não entrará nos
  quadros de pilha de um módulo que corresponda a um desses padrões.
  (Contribuição de Maru Newby após sugestão de Senthil Kumaran;
  bpo-5142.)

* O módulo "binascii" agora oferece suporte à API de buffer, então ele
  pode ser usado com instâncias "memoryview" e outros objetos buffer
  similares. (Backport de 3.x por Florent Xicluna; bpo-7703.)

* Módulo atualizado: o módulo "bsddb" foi atualizado de 4.7.2devel9
  para a versão 4.8.4 do pacote pybsddb. A nova versão apresenta
  melhor compatibilidade com Python 3.x, várias correções de bugs e
  adiciona vários novos sinalizadores e métodos BerkeleyDB.
  (Atualizado por Jesús Cea Avión; bpo-8156. O changelog do pybsddb
  pode ser lido em https://hg.jcea.es/pybsddb/file/tip/ChangeLog.)

* O "BZ2File" do módulo "bz2" agora oferece suporte ao protocolo de
  gerenciamento de contexto, então você pode escrever "with
  bz2.BZ2File(...) as f:". (Contribuição de Hagen Fürstenau;
  bpo-3860.)

* Nova classe: a classe "Counter" no módulo "collections" é útil para
  contabilizar dados. As instâncias "Counter" se comportam
  principalmente como dicionários, mas retornam zero para chaves
  ausentes em vez de levantar uma exceção "KeyError":

     >>> from collections import Counter
     >>> c = Counter()
     >>> for letter in 'here is a sample of english text':
     ...   c[letter] += 1
     ...
     >>> c
     Counter({' ': 6, 'e': 5, 's': 3, 'a': 2, 'i': 2, 'h': 2,
     'l': 2, 't': 2, 'g': 1, 'f': 1, 'm': 1, 'o': 1, 'n': 1,
     'p': 1, 'r': 1, 'x': 1})
     >>> c['e']
     5
     >>> c['z']
     0

  Existem três métodos "Counter" adicionais. "most_common()" retorna
  os N elementos mais comuns e suas contagens. "elements()" retorna um
  iterador sobre os elementos contidos, repetindo cada elemento tantas
  vezes quanto sua contagem. "subtract()" pega um iterável e subtrai
  um para cada elemento em vez de adicionar; se o argumento for um
  dicionário ou outro "Counter", as contagens são subtraídas.

     >>> c.most_common(5)
     [(' ', 6), ('e', 5), ('s', 3), ('a', 2), ('i', 2)]
     >>> c.elements() ->
        'a', 'a', ' ', ' ', ' ', ' ', ' ', ' ',
        'e', 'e', 'e', 'e', 'e', 'g', 'f', 'i', 'i',
        'h', 'h', 'm', 'l', 'l', 'o', 'n', 'p', 's',
        's', 's', 'r', 't', 't', 'x'
     >>> c['e']
     5
     >>> c.subtract('very heavy on the letter e')
     >>> c['e']    # Count is now lower
     -1

  Contribuição de Raymond Hettinger; bpo-1696199.

  Nova classe: "OrderedDict" é descrita na seção anterior PEP 372:
  Adicionando um dicionário ordenado a coleções.

  Novo método: O tipo de dados "deque" agora tem um método "count()"
  que retorna o número de elementos contidos igual ao argumento
  fornecido *x*, e um "reverse()" método que inverte os elementos do
  deque no local. "deque" também expõe seu comprimento máximo como o
  atributo somente leitura "maxlen". (Ambos os recursos adicionados
  por Raymond Hettinger.)

  A classe "namedtuple" agora possui um parâmetro opcional *rename*.
  Se *rename* for verdadeiro, os nomes de campos inválidos porque
  foram repetidos ou não são identificadores Python legais serão
  renomeados para nomes legais derivados da posição do campo na lista
  de campos:

  >>> from collections import namedtuple
  >>> T = namedtuple('T', ['field1', '$illegal', 'for', 'field2'], rename=True)
  >>> T._fields
  ('field1', '_1', '_2', 'field2')

  (Adição de Raymond Hettinger; bpo-1818.)

  Finalmente, a classe base abstrata "Mapping" agora retorna
  "NotImplemented" se um mapeamento for comparado a outro tipo que não
  seja um "Mapping". (Correção de Daniel Stutzbach; bpo-8729.)

* Construtores para as classes de análise no módulo "ConfigParser"
  agora recebem um parâmetro *allow_no_value*, cujo padrão é false; se
  verdadeiro, opções sem valores serão permitidas. Por exemplo:

     >>> import ConfigParser, StringIO
     >>> sample_config = """
     ... [mysqld]
     ... user = mysql
     ... pid-file = /var/run/mysqld/mysqld.pid
     ... skip-bdb
     ... """
     >>> config = ConfigParser.RawConfigParser(allow_no_value=True)
     >>> config.readfp(StringIO.StringIO(sample_config))
     >>> config.get('mysqld', 'user')
     'mysql'
     >>> print config.get('mysqld', 'skip-bdb')
     None
     >>> print config.get('mysqld', 'unknown')
     Traceback (most recent call last):
       ...
     NoOptionError: No option 'unknown' in section: 'mysqld'

  (Contribuição de Mats Kindahl; bpo-7005.)

* Função descontinuada: "contextlib.nested()", que permite lidar com
  mais de um gerenciador de contexto com uma única instrução "with",
  foi descontinuada porque a instrução "with" agora oferece suporte a
  múltiplos contextos gerentes.

* O módulo "cookielib" agora ignora cookies que possuem um campo de
  versão inválido, que não contém um valor inteiro. (Correção de John
  J. Lee; bpo-3924.)

* A função "deepcopy()" do módulo "copy" agora copiará corretamente os
  métodos de instância vinculados. (Implementado por Robert Collins;
  bpo-1515.)

* O módulo "ctypes" agora sempre converte "None" em um ponteiro C
  "NULL" para argumentos declarados como ponteiros. (Alterado por
  Thomas Heller; bpo-4606.) A biblioteca libffi subjacente foi
  atualizada para a versão 3.0.9, contendo várias correções para
  diferentes plataformas. (Atualizado por Matthias Klose; bpo-8142.)

* Novo método: a classe "timedelta" do módulo "datetime" ganhou um
  método "total_seconds()" que retorna o número de segundos na
  duração. (Contribuição de Brian Quinlan; bpo-5788.)

* Novo método: a classe "Decimal" ganhou um método de classe
  "from_float()" que realiza uma conversão exata de um número de ponto
  flutuante para um "Decimal". Essa conversão exata busca a maior
  aproximação decimal do valor da representação de ponto flutuante; o
  valor decimal resultante ainda incluirá a imprecisão, se houver. Por
  exemplo, "Decimal.from_float(0.1)" retorna "Decimal('0.100000000000
  0000055511151231257827021181583404541015625')". (Implementado por
  Raymond Hettinger; bpo-4796.)

  Comparar instâncias de "Decimal" com números de ponto flutuante
  agora produz resultados sensatos com base nos valores numéricos dos
  operandos. Anteriormente, essas comparações recorreriam às regras
  padrão do Python para comparar objetos, que produziam resultados
  arbitrários com base em seu tipo. Observe que você ainda não pode
  combinar "Decimal" e ponto flutuante em outras operações, como
  adição, já que você deve escolher explicitamente como converter
  entre float e "Decimal". (Corrigido por Mark Dickinson; bpo-2531.)

  O construtor para "Decimal" agora aceita números de ponto flutuante
  (adicionados por Raymond Hettinger; bpo-8257) e caracteres Unicode
  não europeus, como dígitos árabe-índicos (contribuição de Mark
  Dickinson; bpo-6595).

  A maioria dos métodos da classe "Context" agora aceitam números
  inteiros, bem como instâncias "Decimal"; as únicas exceções são os
  métodos "canonical()" e "is_canonical()". (Patch de Juan José Conti;
  bpo-7633.)

  Ao usar instâncias "Decimal" com o método "format()" de uma string,
  o alinhamento padrão era anteriormente o alinhamento à esquerda.
  Isso foi alterado para alinhamento à direita, que é mais sensato
  para tipos numéricos. (Alteração de Mark Dickinson; bpo-6857.)

  Comparações envolvendo um valor NaN de sinalização (ou "sNAN") agora
  sinalizam "InvalidOperation" em vez de retornar silenciosamente um
  valor verdadeiro ou falso dependendo do operador de comparação.
  Valores silenciosos de NaN (ou "NaN") agora são hasheáveis.
  (Corrigido por Mark Dickinson; bpo-7279.)

* O módulo "difflib" agora produz uma saída que é mais compatível com
  as ferramentas **diff**/**patch** modernas através de uma pequena
  mudança, usando um caractere de tabulação em vez de espaços como
  separador no cabeçalho, fornecendo o nome do arquivo. (Correção de
  Anatoly Techtonik; bpo-7585.)

* O comando Distutils "sdist" agora sempre regenera o arquivo
  "MANIFEST", pois mesmo que os arquivos "MANIFEST.in" ou "setup.py"
  não tenham sido modificados, o usuário pode ter criado alguns novos
  arquivos que deveriam ser incluídos. (Correção de Tarek Ziadé;
  bpo-8688.)

* O sinalizador "IGNORE_EXCEPTION_DETAIL" do módulo "doctest" irá
  agora ignorar o nome do módulo que contém a exceção que está sendo
  testada. (Patch de Lennart Regebro; bpo-7490.)

* A classe "Message" do módulo "email" agora aceitará uma carga útil
  com valor Unicode, convertendo automaticamente a carga útil para a
  codificação especificada por "output_charset". (Adição de R. David
  Murray; bpo-1368247.)

* A classe "Fraction" agora aceita uma única instância float ou
  "Decimal", ou dois números racionais, como argumentos para seu
  construtor. (Implementação de Mark Dickinson; racionais adicionados
  em bpo-5812 e float/decimal em bpo-8294.)

  Ordenar comparações ("<", "<=", ">", ">=") entre frações e números
  complexos agora levanta um "TypeError". Isso corrige um descuido,
  fazendo com que "Fraction" corresponda aos outros tipos numéricos.

* Nova classe: "FTP_TLS" no módulo "ftplib" fornece conexões FTP
  seguras usando encapsulamento TLS de autenticação, bem como controle
  subsequente e transferências de dados. (Contribuição de Giampaolo
  Rodola; bpo-2054.)

  O método "storbinary()" para envios de binários agora pode reiniciar
  envios graças a um parâmetro *rest* adicionado (patch de Pablo
  Mouzo; bpo-6845.)

* Novo decorador de classe: "total_ordering()" no módulo "functools"
  pega uma classe que define um método "__eq__()" e um de "__lt__()" ,
  "__le__()", "__gt__()" ou "__ge__()" e gera os métodos de comparação
  ausentes. Como o método "__cmp__()" está sendo descontinuado no
  Python 3.x, esse decorador facilita a definição de classes
  ordenadas. (Adicionado por Raymond Hettinger; bpo-5479.)

  Nova função: "cmp_to_key()" usará uma função de comparação de estilo
  antigo que espera dois argumentos e retornará um novo chamável que
  pode ser usado como parâmetro *key* para funções como "sorted()",
  "min()" e "max()", etc. O principal uso pretendido é ajudar a tornar
  o código compatível com Python 3.x. (Adição de Raymond Hettinger.)

* Nova função: o "is_tracked()" do módulo "gc" retorna verdadeiro se
  uma determinada instância for rastreada pelo coletor de lixo, falso
  caso contrário. (Contribuição de Antoine Pitrou; bpo-4688)

* O "GzipFile" do módulo "gzip" agora oferece suporte ao protocolo de
  gerenciamento de contexto, então você pode escrever "with
  gzip.GzipFile(...) as f:" (contribuição de Hagen Fürstenau;
  bpo-3860), e agora implementa o "io.BufferedIOBase" ABC, então você
  pode envolvê-lo com "io.BufferedReader" para processamento mais
  rápido (contribuição de Nir Aides; bpo-7471). Agora também é
  possível substituir o horário de modificação registrado em um
  arquivo compactado, fornecendo um registro de data e hora opcional
  ao construtor. (Contribuição de Jacques Frechet; bpo-4272.)

  Arquivos no formato gzip podem ser preenchidos com zero bytes à
  direita; o módulo "gzip" agora consumirá esses bytes finais.
  (Correção de Tadek Pietraszek e Brian Curtin; bpo-2846.)

* Novo atributo: o módulo "hashlib" agora possui um atributo
  "algorithms" contendo uma tupla nomeando os algoritmos suportados.
  No Python 2.7, "hashlib.algorithms" contém "('md5', 'sha1',
  'sha224', 'sha256', 'sha384', 'sha512')". (Contribuição de Carl
  Chenet; bpo-7418.)

* A classe padrão "HTTPResponse" usada pelo módulo "httplib" agora
  oferece suporte a buffering, resultando em uma leitura muito mais
  rápida de respostas HTTP. (Contribuição de Kristján Valur Jónsson;
  bpo-4879.)

  As classes "HTTPConnection" e "HTTPSConnection" agora oferecem
  suporte a um parâmetro *source_address*, uma tupla de 2 elementos
  "(host, port)" fornecendo o endereço de origem que será usado para a
  conexão. (Contribuição de Eldon Ziegler; bpo-3972.)

* O módulo "ihooks" agora oferece suporte a importações relativas.
  Observe que "ihooks" é um módulo mais antigo para personalizar
  importações, substituído pelo módulo "imputil" adicionado no Python
  2.0. (Suporte relativo à importação adicionado por Neil
  Schemenauer.)

* O módulo "imaplib" agora oferece suporte a endereços IPv6.
  (Contribuição de Derek Morr; bpo-1655.)

* Nova função: "getcallargs()" do módulo "inspect" pega um chamável e
  seus argumentos nomeados e posicionais, e descobre quais dos
  parâmetros do chamável receberão cada argumento, retornando um
  dicionário mapeando nomes de argumentos para seus valores. Por
  exemplo:

     >>> from inspect import getcallargs
     >>> def f(a, b=1, *pos, **named):
     ...     pass
     ...
     >>> getcallargs(f, 1, 2, 3)
     {'a': 1, 'b': 2, 'pos': (3,), 'named': {}}
     >>> getcallargs(f, a=2, x=4)
     {'a': 2, 'b': 1, 'pos': (), 'named': {'x': 4}}
     >>> getcallargs(f)
     Traceback (most recent call last):
     ...
     TypeError: f() takes at least 1 argument (0 given)

  Contribuição de George Sakkis; bpo-3135.

* Módulo atualizado: A biblioteca "io" foi atualizada para a versão
  fornecida com Python 3.1. Para 3.1, a biblioteca de E/S foi
  totalmente reescrita em C e é de 2 a 20 vezes mais rápida dependendo
  da tarefa que está sendo executada. A versão original do Python foi
  renomeada para o módulo "_pyio".

  Uma pequena mudança resultante: a classe "io.TextIOBase" agora tem
  um atributo "errors" fornecendo a configuração de erro usada para
  erros de codificação e decodificação (um dos "'strict'" ,
  "'replace'", "'ignore'").

  A classe "io.FileIO" agora levanta uma exceção "OSError" quando
  passa um descritor de arquivo inválido. (Implementado por Benjamin
  Peterson; bpo-4991.) O método "truncate()" agora preserva a posição
  do arquivo; anteriormente, mudaria a posição do arquivo para o final
  do novo arquivo. (Correção de Pascal Chambon; bpo-6939.)

* Nova função: "itertools.compress(data, selectors)" aceita dois
  iteradores. Elementos de *data* serão retornados se o valor
  correspondente em *selectors* for verdadeiro:

     itertools.compress('ABCDEF', [1,0,1,0,1,1]) =>
       A, C, E, F

  Nova função: "itertools.combinations_with_replacement(iter, r)"
  retorna todas as combinações possíveis de elementos de comprimento
  *r* do *iter* iterável. Ao contrário de "combinations()", elementos
  individuais podem ser repetidos nas combinações geradas:

     itertools.combinations_with_replacement('abc', 2) =>
       ('a', 'a'), ('a', 'b'), ('a', 'c'),
       ('b', 'b'), ('b', 'c'), ('c', 'c')

  Observe que os elementos são tratados como únicos dependendo de sua
  posição na entrada, não de seus valores reais.

  A função "itertools.count()" agora tem um argumento *step* que
  permite incrementar por valores diferentes de 1. "count()" agora
  também permite argumentos nomeados e o uso de valores não inteiros,
  como floats ou "Decimal" instâncias. (Implementação de Raymond
  Hettinger; bpo-5032.)

  "itertools.combinations()" e "itertools.product()" anteriormente
  levantavam "ValueError" para valores de *r* maiores que o iterável
  de entrada. Isto foi considerado um erro de especificação, então
  agora elas retornam um iterador vazio. (Corrigido por Raymond
  Hettinger; bpo-4816.)

* Módulo atualizado: O módulo "json" foi atualizado para a versão
  2.0.9 do pacote simplejson, que inclui uma extensão C que torna a
  codificação e decodificação mais rápidas. (Contribuição de Bob
  Ippolito; bpo-4136.)

  Para oferecer suporte ao novo tipo "collections.OrderedDict",
  "json.load()" agora tem um parâmetro opcional *object_pairs_hook*
  que será chamado com qualquer literal de objeto que decodifica para
  uma lista de pares. (Contribuição de Raymond Hettinger; bpo-5381.)

* A classe "Maildir" do módulo "mailbox" agora registra o registro de
  data e hora nos diretórios que lê, e apenas os relê se o horário de
  modificação for alterado posteriormente. Isso melhora o desempenho,
  evitando varreduras de diretório desnecessárias. (Corrigido por AM
  Kuchling e Antoine Pitrou; bpo-1607951, bpo-6896.)

* Novas funções: o módulo "math" ganhou "erf()" e "erfc()" para a
  função de erro e a função de erro complementar, "expm1()" que
  calcula "e**x - 1" com mais precisão do que usar "exp()" e subtrair
  1, "gamma()" para a função Gamma, e "lgamma()" para o log natural da
  função Gamma. (Contribuição de Mark Dickinson e nirinA raseliarison;
  bpo-3366.)

* As classes "Manager*" do módulo "multiprocessing" agora podem
  receber um chamável que será chamado sempre que um subprocesso for
  iniciado, junto com um conjunto de argumentos que serão passados
  para o chamável. (Contribuição de lekma; bpo-5585.)

  A classe "Pool", que controla um conjunto de processos de trabalho,
  agora possui um parâmetro opcional *maxtasksperchild*. Os processos
  de trabalho executarão o número especificado de tarefas e então
  sairão, fazendo com que "Pool" inicie um novo trabalhador. Isso é
  útil se as tarefas puderem vazar memória ou outros recursos, ou se
  algumas tarefas fizerem com que o trabalho fique muito grande.
  (Contribuição de Charles Cazabon; bpo-6963.)

* O módulo "nntplib" agora oferece suporte para endereços IPv6.
  (Contribuição de Derek Morr; bpo-1664.)

* Novas funções: o módulo "os" envolve as seguintes chamadas de
  sistema POSIX: "getresgid()" e "getresuid()", que retornam os GIDs e
  UIDs reais, efetivos e salvos ; "setresgid()" e "setresuid()", que
  definem GIDs e UIDs reais, efetivos e salvos para novos valores;
  "initgroups()", que inicializa a lista de acesso do grupo para o
  processo atual. (Funções GID/UID foram contribuição de Travis H.;
  bpo-6508. Suporte para initgroups adicionado por Jean-Paul
  Calderone; bpo-7333.)

  A função "os.fork()" agora reinicializa a trava de importação no
  processo filho; isso corrige problemas no Solaris quando "fork()" é
  chamado de um thread. (Correção de Zsolt Cserna; bpo-7242.)

* No módulo "os.path", as funções "normpath()" e "abspath()" agora
  preservam o Unicode; se o caminho de entrada for uma string Unicode,
  o valor de retorno também será uma string Unicode. ("normpath()"
  corrigido por Matt Giuca em bpo-5827; "abspath()" corrigido por Ezio
  Melotti em bpo-3426.)

* O módulo "pydoc" agora tem ajuda para os vários símbolos que o
  Python usa. Agora você pode fazer "help('<<')" ou "help('@')", por
  exemplo. (Contribuição de David Laban; bpo-4739.)

* Os módulos "re" "split()", "sub()" e "subn()" agora aceitam um
  argumento opcional *flags*, para consistência com as outras funções
  do módulo. (Adição de Gregory P. Smith.)

* Nova função: "run_path()" no módulo "runpy" executará o código em um
  argumento *path* fornecido. *path* pode ser o caminho de um arquivo
  fonte Python ("example.py"), um arquivo de bytecode compilado
  ("example.pyc"), um diretório ("./package/") ou um arquivo zip
  ("example.zip"). Se um diretório ou zip path for fornecido, ele será
  adicionado na frente de "sys.path" e o módulo "__main__" será
  importado. É esperado que o diretório ou zip contenha um
  "__main__.py"; caso contrário, algum outro "__main__.py" poderá ser
  importado de um local posteriormente em "sys.path". Isso torna mais
  o maquinário de "runpy" disponível para scripts que desejam imitar a
  maneira como a linha de comando do Python processa um nome de
  caminho explícito. (Adição de Nick Coghlan; bpo-6816.)

* Nova função: no módulo "shutil", "make_archive()" pega um nome de
  arquivo, tipo de arquivo (formato zip ou tar) e um caminho de
  diretório, e cria um arquivo contendo o conteúdo do diretório.
  (Adição de Tarek Ziadé.)

  As funções "copyfile()" e "copytree()" de "shutil" agora levantam
  uma exceção "SpecialFileError" quando solicitado a copiar um
  encadeamento nomeado. Anteriormente, o código trataria pipes
  nomeados como um arquivo normal, abrindo-os para leitura, e isso
  seria bloqueado indefinidamente. (Correção de Antoine Pitrou;
  bpo-3002.)

* O módulo "signal" não reinstala mais o manipulador de sinal a menos
  que isso seja realmente necessário, o que corrige um bug que poderia
  tornar impossível capturar o sinal EINTR de forma robusta. (Correção
  de Charles-François Natali; bpo-8354.)

* Novas funções: no módulo "site", três novas funções retornam vários
  caminhos específicos do site e do usuário. "getsitepackages()"
  retorna uma lista contendo todos os diretórios globais de pacotes de
  sites, "getusersitepackages()" retorna o caminho do diretório de
  pacotes de sites do usuário e "getuserbase()" retorna o valor da
  variável de ambiente "USER_BASE", fornecendo o caminho para um
  diretório que pode ser usado para armazenar dados. (Contribuição de
  Tarek Ziadé; bpo-6693.)

  O módulo "site" agora reporta exceções que ocorrem quando o módulo
  "sitecustomize" é importado, e não irá mais capturar e engolir a
  exceção "KeyboardInterrupt". (Correção de Victor Stinner; bpo-3137.)

* A função "create_connection()" ganhou um parâmetro *source_address*,
  uma tupla de 2 elementos "(host, port)" fornecendo o endereço de
  origem que será usado para a conexão. (Contribuição de Eldon
  Ziegler; bpo-3972.)

  Os métodos "recv_into()" e "recvfrom_into()" agora escreverão em
  objetos que oferecem suporte à API de buffer, mais utilmente objetos
  "bytearray" e "memoryview". (Implementação de Antoine Pitrou;
  bpo-8104.)

* A classe "TCPServer" do módulo "SocketServer" agora oferece suporte
  a limite de tempo de soquete e desativação do algoritmo Nagle. O
  atributo de classe "disable_nagle_algorithm" é padronizado como
  "False"; se substituído como verdadeiro, novas conexões de
  solicitação terão a opção TCP_NODELAY definida para evitar o
  armazenamento em buffer de muitos envios pequenos em um único pacote
  TCP. O atributo de classe "timeout" pode conter um tempo limite em
  segundos que será aplicado ao soquete de solicitação; se nenhuma
  solicitação for recebida dentro desse tempo, "handle_timeout()" será
  chamado e "handle_request()" retornará. (Contribuição de Kristján
  Valur Jónsson; bpo-6192 e bpo-6267.)

* Módulo atualizado: o módulo "sqlite3" foi atualizado para a versão
  2.6.0 do pacote pysqlite. A versão 2.6.0 inclui uma série de
  correções de bugs e adiciona a capacidade de carregar extensões
  SQLite de bibliotecas compartilhadas. Chame o método
  "enable_load_extension(True)" para habilitar extensões, e então
  chame "load_extension()" para carregar uma biblioteca compartilhada
  específica. (Atualização de Gerhard Häring.)

* Os objetos "SSLSocket" do módulo "ssl" agora oferecem suporte à API
  de buffer, que corrigiu uma falha no conjunto de testes (correção
  por Antoine Pitrou; bpo-7133) e definiu automaticamente o
  "SSL_MODE_AUTO_RETRY" do OpenSSL, o que impedirá que um código de
  erro seja retornado de operações "recv()" que acionam uma
  renegociação SSL (correção por Antoine Pitrou; bpo-8222).

  A função construtora "wrap_socket()" agora recebe um argumento
  *ciphers* que é uma string listando os algoritmos de criptografia a
  serem permitidos; o formato da string é descrito na documentação do
  OpenSSL. (Adição de Antoine Pitrou; bpo-8322.)

  Outra mudança faz com que a extensão carregue todas as cifras e
  algoritmos de resumo do OpenSSL para que estejam todos disponíveis.
  Não foi possível verificar alguns certificados SSL, reportando um
  erro de "algoritmo desconhecido". (Relato de Beda Kosata e correção
  de Antoine Pitrou; bpo-8484.)

  A versão do OpenSSL usada agora está disponível como os atributos do
  módulo "ssl.OPENSSL_VERSION" (uma string),
  "ssl.OPENSSL_VERSION_INFO" (uma tupla de 5) e
  "ssl.OPENSSL_VERSION_NUMBER" (um número inteiro). (Adição de Antoine
  Pitrou; bpo-8321.)

* O módulo "struct" não irá mais ignorar silenciosamente erros de
  overflow quando um valor for muito grande para um código de formato
  inteiro específico (um de "bBhHiIlLqQ"); agora sempre levanta uma
  exceção "struct.error". (Alteração de Mark Dickinson; bpo-1523.) A
  função "pack()" também tentará usar "__index__()" para converter e
  empacotar números não inteiros antes de tentar o método "__int__()"
  ou relatar um erro. (Alteração de Mark Dickinson; bpo-8300.)

* Nova função: o "check_output()" do módulo "subprocess" executa um
  comando com um conjunto especificado de argumentos e retorna a saída
  do comando como uma string quando o comando é executado sem erros,
  ou levanta uma exceção "CalledProcessError" caso contrário.

     >>> subprocess.check_output(['df', '-h', '.'])
     'Filesystem     Size   Used  Avail Capacity  Mounted on\n
     /dev/disk0s2    52G    49G   3.0G    94%    /\n'

     >>> subprocess.check_output(['df', '-h', '/bogus'])
       ...
     subprocess.CalledProcessError: Command '['df', '-h', '/bogus']' returned non-zero exit status 1

  (Contribuição de Gregory P. Smith.)

  O módulo "subprocess" agora tentará novamente suas chamadas internas
  do sistema ao receber um sinal "EINTR". (Relato por várias pessoas;
  patch final por Gregory P. Smith em bpo-1068268.)

* Nova função: "is_declared_global()" no módulo "symtable" retorna
  verdadeiro para variáveis que são explicitamente declaradas como
  globais, falso para aquelas que são implicitamente globais.
  (Contribuição de Jeremy Hylton.)

* O módulo "syslog" agora usará o valor de "sys.argv[0]" como
  identificador em vez do valor padrão anterior de "'python'".
  (Alteração de Sean Reifschneider; bpo-8451.)

* O valor "sys.version_info" agora é uma tupla nomeada, com atributos
  chamados "major", "minor", "micro", "releaselevel" e "serial".
  (Contribuição de Ross Light; bpo-4285.)

  "sys.getwindowsversion()" também retorna uma tupla nomeada, com
  atributos chamados "major", "minor", "build", "platform",
  "service_pack", "service_pack_major", "service_pack_minor",
  "suite_mask" e "product_type". (Contribuição de Brian Curtin;
  bpo-7766.)

* O tratamento de erros padrão do módulo "tarfile" foi alterado, para
  não mais suprimir erros fatais. O nível de erro padrão era
  anteriormente 0, o que significava que os erros resultariam apenas
  na gravação de uma mensagem no log de depuração, mas como o log de
  depuração não está ativado por padrão, esses erros passam
  despercebidos. O nível de erro padrão agora é 1, o que levanta uma
  exceção se houver um erro. (Alteração de Lars Gustäbel; bpo-7357.)

  "tarfile" agora oferece suporte à filtragem de objetos "TarInfo"
  sendo adicionados a um arquivo tar. Quando você chama "add()", você
  pode fornecer um argumento *filter* opcional que é chamável. O
  chamável *filter* receberá o "TarInfo" para cada arquivo sendo
  adicionado, e pode modificá-lo e retorná-lo. Se o chamável retornar
  "None", o arquivo será excluído do arquivo resultante. Isto é mais
  poderoso do que o argumento *exclude* existente, que foi, portanto,
  descontinuado. (Adição de Lars Gustäbel; bpo-6856.) A classe
  "TarFile" agora também oferece suporte ao protocolo de gerenciamento
  de contexto. (Adição de Lars Gustäbel; bpo-7232.)

* O método "wait()" da classe "threading.Event" agora retorna o
  sinalizador interno na saída. Isso significa que o método geralmente
  retornará verdadeiro porque "wait()" deve ser bloqueado até que o
  sinalizador interno se torne verdadeiro. O valor de retorno só será
  falso se um tempo limite tiver sido fornecido e a operação tiver
  expirado. (Contribuição de Tim Lesher; bpo-1674032.)

* O banco de dados Unicode fornecido pelo módulo "unicodedata" agora é
  usado internamente para determinar quais caracteres são numéricos,
  espaços em branco ou representam quebras de linha. O banco de dados
  também inclui informações do arquivo de dados "Unihan.txt" (patch de
  Anders Chrigström e Amaury Forgeot d'Arc; bpo-1571184) e foi
  atualizado para a versão 5.2.0 (atualização de Florent Xicluna;
  bpo-8024).

* A função "urlsplit()" do módulo "urlparse" agora lida com esquemas
  de URL desconhecidos de uma forma compatível com **RFC 3986**: se a
  URL estiver no formato ""<alguma_coisa>://..."", o texto antes de
  "://" é tratado como o esquema, mesmo que seja um esquema inventado
  que o módulo não conhece. Essa alteração pode quebrar o código que
  contornava o comportamento antigo. Por exemplo, Python 2.6.4 ou 2.5
  retornará o seguinte:

     >>> import urlparse
     >>> urlparse.urlsplit('invented://host/filename?query')
     ('invented', '', '//host/filename?query', '', '')

  Python 2.7 (e Python 2.6.5) vai retornar:

     >>> import urlparse
     >>> urlparse.urlsplit('invented://host/filename?query')
     ('invented', 'host', '/filename?query', '', '')

  (Na verdade, o Python 2.7 produz uma saída ligeiramente diferente,
  pois retorna uma tupla nomeada em vez de uma tupla padrão.)

  O módulo "urlparse" também oferece suporte a endereços IPv6 literais
  conforme definido pelo **RFC 2732** (contribuição de Senthil
  Kumaran; bpo-2987).

     >>> urlparse.urlparse('http://[1080::8:800:200C:417A]/foo')
     ParseResult(scheme='http', netloc='[1080::8:800:200C:417A]',
                 path='/foo', params='', query='', fragment='')

* Nova classe: a classe "WeakSet" no módulo "weakref" é um conjunto
  que contém apenas referências fracas aos seus elementos; os
  elementos serão removidos quando não houver referências apontando
  para eles. (Originalmente implementado em Python 3.x por Raymond
  Hettinger e portado para 2.7 por Michael Foord.)

* A biblioteca "xml.etree.ElementTree" não escapa mais caracteres de E
  comercial e de sinal de maior e de menor ao gerar uma instrução de
  processamento XML (que se parece com "<?xml-stylesheet
  href="#style1"?>") ou comentário (que se parece com "<!-- comentário
  -->"). (Patch de Neil Muller; bpo-2746.)

* O cliente e servidor de XML-RPC, fornecidos pelos módulos
  "xmlrpclib" e "SimpleXMLRPCServer", melhoraram o desempenho ao
  prover suporte a kep-alive do HTTP/1.1 e, opcionalmente, usando a
  codificação gzip para compactar o XML que está sendo trocado. A
  compactação gzip é controlada pelo atributo "encode_threshold" de
  "SimpleXMLRPCRequestHandler", que contém um tamanho em bytes;
  respostas maiores que isso serão compactadas. (Contribuição de
  Kristján Valur Jónsson; bpo-6267.)

* A classe "ZipFile" do módulo "zipfile" agora oferece suporte ao
  protocolo de gerenciamento de contexto, então você pode escrever
  "with zipfile.ZipFile(...) as f:". (Contribuição de Brian Curtin;
  bpo-5511.)

  "zipfile" agora também oferece suporte ao arquivamento de diretórios
  vazios e os extrai corretamente. (Correção de Kuba Wieczorek;
  bpo-4710.) Ler arquivos de um arquivo é mais rápido e intercalar
  "read()" e "readline()" agora funciona corretamente. (Contribuição
  de Nir Aides; bpo-7610.)

  A função "is_zipfile()" agora aceita um objeto arquivo, além dos
  nomes de caminho aceitos em versões anteriores. (Contribuição de
  Gabriel Genellina; bpo-4756.)

  O método "writestr()" agora tem um parâmetro *compress_type*
  opcional que permite substituir o método de compactação padrão
  especificado no construtor de "ZipFile". (Contribuição de Ronald
  Oussoren; bpo-6003.)


Novo módulo: importlib
----------------------

Python 3.1 inclui o pacote "importlib", uma reimplementação da lógica
subjacente à instrução "import" do Python. "importlib" é útil para
implementadores de interpretadores Python e para usuários que desejam
escrever novos importadores que possam participar do processo de
importação. Python 2.7 não contém o pacote "importlib" completo, mas
em vez disso possui um pequeno subconjunto que contém uma única
função, "import_module()".

"import_module(name, package=None)" importa um módulo. *name* é uma
string contendo o nome do módulo ou pacote. É possível fazer
importações relativas fornecendo uma string que começa com um
caractere ".", como "..utils.errors". Para importações relativas, o
argumento *package* deve ser fornecido e é o nome do pacote que será
usado como âncora para a importação relativa. "import_module()" insere
o módulo importado em "sys.modules" e retorna o objeto do módulo.

Veja alguns exemplos:

   >>> from importlib import import_module
   >>> anydbm = import_module('anydbm')  # Importação absoluta padrão
   >>> anydbm
   <module 'anydbm' from '/p/python/Lib/anydbm.py'>
   >>> # Importação relativa
   >>> file_util = import_module('..file_util', 'distutils.command')
   >>> file_util
   <module 'distutils.file_util' from '/python/Lib/distutils/file_util.pyc'>

"importlib" foi implementado por Brett Cannon e introduzido no Python
3.1.


Novo módulo: sysconfig
----------------------

O módulo "sysconfig" foi retirado do pacote Distutils, tornando-se um
novo módulo de nível independente. "sysconfig" fornece funções para
obter informações sobre o processo de construção do Python: opções do
compilador, caminhos de instalação, o nome da plataforma e se o Python
está sendo executado a partir de seu diretório de código-fonte.

Algumas das funções do módulo são:

* "get_config_var()" retorna variáveis do Makefile do Python e do
  arquivo "pyconfig.h".

* "get_config_vars()" retorna um dicionário contendo todas as
  variáveis de configuração.

* "get_path()" retorna o caminho configurado para um tipo específico
  de módulo: a biblioteca padrão, módulos específicos do site, módulos
  específicos da plataforma, etc.

* "is_python_build()" retorna verdadeiro se você estiver executando um
  binário de uma árvore de código-fonte em Python, e falso caso
  contrário.

Consulte a documentação do "sysconfig" para mais detalhes e para uma
lista completa de funções.

O pacote Distutils e "sysconfig" agora são mantidos por Tarek Ziadé,
que também iniciou um pacote Distutils2 (repositório fonte em
https://hg.python.org/distutils2/) para desenvolver uma versão de
próxima geração do Distutils.


ttk: Widgets temáticos para Tk
------------------------------

O Tcl/Tk 8.5 inclui um conjunto de widgets temáticos que reimplementam
widgets Tk básicos, mas têm uma aparência mais personalizável e podem,
portanto, se assemelhar mais aos widgets da plataforma nativa. Este
conjunto de widgets foi originalmente chamado de Tile, mas foi
renomeado para Ttk (para "Tk temático") ao ser adicionado ao Tcl/Tck
versão 8.5.

Para saber mais, leia a documentação do módulo "ttk". Você também pode
ler a página de manual do Tcl/Tk que descreve o mecanismo do tema Ttk,
disponível em https://www.tcl.tk/man/tcl8.5/TkCmd/ttk_intro.html.
Algumas capturas de tela do código Python/Ttk em uso estão em
https://code.google.com/archive/p/python-ttk/wikis/Screenshots.wiki.

O módulo "tkinter.ttk" foi escrito por Guilherme Polo e adicionado em
bpo-2983. Uma versão alternativa chamada "Tile.py", escrita por Martin
Franklin e mantida por Kevin Walzer, foi proposta para inclusão em
bpo-2618, mas os autores argumentaram que o trabalho de Guilherme Polo
era mais abrangente.


Módulo atualizado: unittest
---------------------------

O módulo "unittest" foi bastante aprimorado; muitos novos recursos
foram adicionados. A maioria desses recursos foi implementada por
Michael Foord, salvo indicação em contrário. A versão aprimorada do
módulo pode ser baixada separadamente para uso com as versões 2.4 a
2.6 do Python, empacotadas como o pacote "unittest2", de unittest2.

Quando usado na linha de comando, o módulo pode descobrir testes
automaticamente. Não é tão sofisticado quanto py.test ou nose, mas
fornece uma maneira simples de executar testes mantidos dentro de um
conjunto de diretórios de pacotes. Por exemplo, o comando a seguir irá
pesquisar no subdiretório "test/" por quaisquer arquivos de teste
importáveis chamados "test*.py":

   python -m unittest discover -s test

Consulte a documentação do módulo "unittest" para mais detalhes.
(Desenvolvido em bpo-6001.)

A função "main()" oferece suporte a algumas outras novas opções:

* "-b" ou "--buffer" armazenará em buffer a saída padrão e os fluxos
  de erro padrão durante cada teste. Se o teste for aprovado, qualquer
  saída resultante será descartada; em caso de falha, a saída em
  buffer será exibida.

* "-c" ou "--catch" fará com que a interrupção control-C seja tratada
  com mais elegância. Em vez de interromper imediatamente o processo
  de teste, o teste em execução será concluído e então os resultados
  parciais até a interrupção serão relatados. Se você estiver
  impaciente, um segundo toque no controle C causará uma interrupção
  imediata.

  Este manipulador de control-C tenta evitar causar problemas quando o
  código que está sendo testado ou os testes em execução definiram um
  manipulador de sinal próprio, percebendo que um manipulador de sinal
  já estava definido e chamando-o. Se isso não funcionar para você,
  existe um decorador "removeHandler()" que pode ser usado para marcar
  testes que devem ter o manuseio de control-C desabilitado.

* "-f" ou "--failfast" faz com que a execução do teste pare
  imediatamente quando um teste falha, em vez de continuar a executar
  testes adicionais. (Sugerido por Cliff Dyer e implementado por
  Michael Foord; bpo-8074.)

As mensagens de progresso agora mostram 'x' para falhas esperadas e
'u' para sucessos inesperados quando executadas em modo detalhado.
(Contribuição de Benjamin Peterson.)

Os casos de teste podem levantar a exceção "SkipTest" para pular um
teste (bpo-1034053).

As mensagens de erro para falhas "assertEqual()", "assertTrue()" e
"assertFalse()" agora fornecem mais informações. Se você definir o
atributo "longMessage" de suas classes "TestCase" como true, tanto a
mensagem de erro padrão quanto qualquer mensagem adicional que você
fornecer serão impressas para falhas. (Adição de Michael Foord;
bpo-5663.)

O método "assertRaises()" agora retorna um manipulador de contexto
quando chamado sem fornecer um objeto chamável para ser executado. Por
exemplo, você pode escrever isto:

   with self.assertRaises(KeyError):
       {}['foo']

(implementação de Antoine Pitrou; bpo-4444.)

Correções de desmontagem e configuração em nível de módulo e classe
agora são suportados. Os módulos podem conter funções "setUpModule()"
e "tearDownModule()". As classes podem ter métodos "setUpClass()" e
"tearDownClass()" que devem ser definidos como métodos de classe
(usando "@classmethod" ou equivalente). Essas funções e métodos são
invocados quando o executor de teste alterna para um caso de teste em
um módulo ou classe diferente.

Os métodos "addCleanup()" e "doCleanups()" foram adicionados.
"addCleanup()" permite adicionar funções de limpeza que serão chamadas
incondicionalmente (após "setUp()" se "setUp()" falhar, caso
contrário, após "tearDown()"). Isso permite uma alocação e desalocação
de recursos muito mais simples durante os testes (bpo-5679).

Foram adicionados vários novos métodos que fornecem testes mais
especializados. Muitos desses métodos foram escritos por engenheiros
do Google para uso em seus conjuntos de testes; Gregory P. Smith,
Michael Foord e GvR trabalharam na fusão deles na versão Python de
"unittest".

* "assertIsNone()" e "assertIsNotNone()" pegam uma expressão e
  verificam se o resultado é ou não "None".

* "assertIs()" e "assertIsNot()" pegam dois valores e verificam se os
  dois valores são avaliados como o mesmo objeto ou não. (Adicionado
  por Michael Foord; bpo-2578.)

* "assertIsInstance()" e "assertNotIsInstance()" verificam se o objeto
  resultante é uma instância de uma classe específica ou de uma tupla
  de classes. (Adicionado por Georg Brandl; bpo-7031.)

* "assertGreater()", "assertGreaterEqual()", "assertLess()", e
  "assertLessEqual()" comparam duas quantidades.

* "assertMultiLineEqual()" compara duas strings e, se não forem
  iguais, exibe uma comparação útil que destaca as diferenças nas duas
  strings. Esta comparação agora é usada por padrão quando strings
  Unicode são comparadas com "assertEqual()".

* "assertRegexpMatches()" e "assertNotRegexpMatches()" verificam se o
  primeiro argumento é uma string que corresponde ou não à expressão
  regular fornecida como o segundo argumento (bpo-8038).

* "assertRaisesRegexp()" verifica se uma exceção específica foi
  levantada e também verifica se a representação da string da exceção
  corresponde à expressão regular fornecida.

* "assertIn()" e "assertNotIn()" testa se *primeiro* está ou não em
  *segundo*.

* "assertItemsEqual()" testa se duas sequências fornecidas contêm os
  mesmos elementos.

* "assertSetEqual()" compara se dois conjuntos são iguais e apenas
  relata as diferenças entre os conjuntos em caso de erro.

* Da mesma forma, "assertListEqual()" e "assertTupleEqual()" comparam
  os tipos especificados e explicam quaisquer diferenças sem
  necessariamente imprimir seus valores completos; esses métodos agora
  são usados por padrão ao comparar listas e tuplas usando
  "assertEqual()". De forma mais geral, "assertSequenceEqual()"
  compara duas sequências e pode opcionalmente verificar se ambas as
  sequências são de um tipo específico.

* "assertDictEqual()" compara dois dicionários e relata as diferenças;
  agora é usado por padrão quando você compara dois dicionários usando
  "assertEqual()". "assertDictContainsSubset()" verifica se todos os
  pares chave/valor em *first* são encontrados em *second*.

* "assertAlmostEqual()" e "assertNotAlmostEqual()" testam se *first* e
  *second* são aproximadamente iguais. Este método pode arredondar a
  diferença para um número opcionalmente especificado de *places* (o
  padrão é 7) e compará-lo com zero, ou exigir que a diferença seja
  menor que um valor *delta* fornecido.

* "loadTestsFromName()" respeita corretamente o atributo "suiteClass"
  do "TestLoader". (Correção de Mark Roddy; bpo-6866.)

* Um novo gancho permite estender o método "assertEqual()" para lidar
  com novos tipos de dados. O método "addTypeEqualityFunc()" leva um
  objeto de tipo e uma função. A função será usada quando ambos os
  objetos comparados forem do tipo especificado. Esta função deve
  comparar os dois objetos e gerar uma exceção se eles não
  corresponderem; é uma boa ideia que a função forneça informações
  adicionais sobre por que os dois objetos não correspondem, assim
  como fazem os novos métodos de comparação de sequências.

"unittest.main()" agora recebe um argumento "exit" opcional.  Se for
falso, "main()" não chama "sys.exit()", permitindo que "main()" seja
usado a partir do interpretador interativo.  (Contribuição de J. Pablo
Fernández; bpo-3379.)

"TestResult" tem novos métodos "startTestRun()" e "stopTestRun()" que
são chamados imediatamente antes e depois de uma execução de teste.
(Contribuição de Robert Collins; bpo-5728.)

Com todas essas mudanças, o "unittest.py" estava ficando estranhamente
grande, então o módulo foi transformado em um pacote e o código
dividido em vários arquivos (por Benjamin Peterson). Isso não afeta
como o módulo é importado ou usado.

Ver também:

  https://web.archive.org/web/20210619163128/http://www.voidspace.org
  .uk/python/articles/unittest2.shtml
     Descreve os novos recursos, como usá-los e a justificativa para
     diversas decisões de design. (Por Michael Foord.)


Módulo atualizado: ElementTree 1.3
----------------------------------

A versão da biblioteca ElementTree incluída no Python foi atualizada
para a versão 1.3. Alguns dos novos recursos são:

* As várias funções de análise agora recebem um argumento nomeado
  *parser* fornecendo uma instância "XMLParser" que será usada. Isso
  torna possível substituir a codificação interna do arquivo:

     p = ET.XMLParser(encoding='utf-8')
     t = ET.XML("""<root/>""", parser=p)

  Erros na análise de XML agora levantam uma exceção "ParseError",
  cujas instâncias possuem um atributo "position" contendo uma tupla
  (*linha*, *coluna*) fornecendo a localização do problema.

* O código do ElementTree para converter árvores em strings foi
  significativamente reformulado, tornando-o quase duas vezes mais
  rápido em muitos casos. Os métodos "ElementTree.write()" e
  "Element.write()" agora têm um parâmetro *method* que pode ser "xml"
  (o padrão), "html" ou "text". O modo HTML exibirá elementos vazios
  como "<empty></empty>" em vez de "<empty/>", e o modo texto ignorará
  os elementos e exibirá apenas os blocos de texto. Se você definir o
  atributo "tag" de um elemento como "None", mas deixar seus filhos no
  lugar, o elemento será omitido quando a árvore for gravada,
  portanto, não será necessário fazer uma reorganização mais extensa
  para remover um único elemento.

  O tratamento de espaços de nomes também foi aprimorado. Todas as
  declarações "xmlns:<alguma-coisa>" agora são geradas no elemento
  raiz, e não espalhadas pelo XML resultante. Você pode definir o
  espaço de nomes padrão para uma árvore definindo o atributo
  "default_namespace" e registrar novos prefixos com
  "register_namespace()". No modo XML, você pode usar o parâmetro
  true/false *xml_declaration* para suprimir a declaração XML.

* Novo método "Element": "extend()" anexa os itens de uma sequência
  aos filhos do elemento. Os próprios elementos se comportam como
  sequências, por isso é fácil mover os filhos de um elemento para
  outro:

     from xml.etree import ElementTree as ET

     t = ET.XML("""<list>
       <item>1</item> <item>2</item>  <item>3</item>
     </list>""")
     new = ET.XML('<root/>')
     new.extend(t)

     # Outputs <root><item>1</item>...</root>
     print ET.tostring(new)

* Novo método "Element": "iter()" produz os filhos do elemento como um
  gerador. Também é possível escrever "for child in elem:" para
  percorrer os filhos de um elemento. O método existente
  "getiterator()" agora está descontinuado, assim como "getchildren()"
  que constrói e retorna uma lista de filhos.

* Novo método "Element": "itertext()" produz todos os pedaços de texto
  que são descendentes do elemento. Por exemplo:

     t = ET.XML("""<list>
       <item>1</item> <item>2</item>  <item>3</item>
     </list>""")

     # Outputs ['\n  ', '1', ' ', '2', '  ', '3', '\n']
     print list(t.itertext())

* Descontinuado: usar um elemento como booleano (ou seja, "if elem:")
  retornaria verdadeiro se o elemento tivesse algum filho, ou falso se
  não houvesse nenhum filho. Este comportamento é confuso -- "None" é
  falso, mas um elemento sem filhos também o é? -- então agora irá
  acionar um "FutureWarning". Em seu código, você deve ser explícito:
  escreva "len(elem) != 0" se estiver interessado no número de filhos,
  ou "elem is not None".

Fredrik Lundh desenvolve ElementTree e produziu a versão 1.3; você
pode ler o artigo dele descrevendo 1.3 em https://web.archive.org/web
/20200703234532/http://effbot.org/zone/elementtree-13-intro.htm.
Florent Xicluna atualizou a versão incluída no Python, após discussões
em python-dev e em bpo-6472.)


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

As alterações no processo de construção do Python e na API C incluem:

* O uso da versão mais recente do GNU Debugger, GDB 7, pode ser
  programado usando Python. Quando você começa a depurar um programa
  executável P, o GDB irá procurar por um arquivo chamado "P-gdb.py" e
  lê-lo automaticamente. Dave Malcolm contribuiu com um "python-
  gdb.py" que adiciona vários comandos úteis ao depurar o próprio
  Python. Por exemplo, "py-up" e "py-down" sobem ou descem um quadro
  de pilha Python, que geralmente corresponde a vários quadros de
  pilha C. "py-print" imprime o valor de uma variável Python e "py-bt"
  imprime o stack trace do Python. (Adicionado como resultado de
  bpo-8032.)

* Se você usar o arquivo ".gdbinit" fornecido com Python, a macro
  "pyo" na versão 2.7 agora funciona corretamente quando o thread que
  está sendo depurado não contém a GIL; a macro agora a adquire antes
  de imprimir. (Contribuição de Victor Stinner; bpo-3632.)

* "Py_AddPendingCall()" agora é segura para thread, permitindo que
  qualquer thread de trabalho envie notificações para o thread
  principal do Python. Isto é particularmente útil para operações de
  E/S assíncronas. (Contribuição de Kristján Valur Jónsson; bpo-4293.)

* Nova função: "PyCode_NewEmpty()" cria um objeto código vazio; apenas
  o nome do arquivo, o nome da função e o número da primeira linha são
  necessários. Isto é útil para módulos de extensão que estão tentando
  construir uma pilha de traceback mais útil. Anteriormente, essas
  extensões precisavam chamar "PyCode_New()", que tinha muito mais
  argumentos. (Adição de Jeffrey Yasskin.)

* Nova função: "PyErr_NewExceptionWithDoc()" cria uma nova classe de
  exceção, assim como a "PyErr_NewException()" existente faz, mas
  recebe um argumento "char *" extra contendo a docstring para a nova
  classe de exceção . (Adição de 'lekma' no rastreador de bugs do
  Python; bpo-7033.)

* Nova função: "PyFrame_GetLineNumber()" pega um objeto quadro e
  retorna o número da linha que o frame está executando atualmente.
  Anteriormente, o código precisaria obter o índice da instrução de
  bytecode atualmente em execução e, em seguida, procurar o número da
  linha correspondente a esse endereço. (Adição de Jeffrey Yasskin.)

* Novas funções: "PyLong_AsLongAndOverflow()" e
  "PyLong_AsLongLongAndOverflow()" aproxima um inteiro longo do Python
  como um long ou long long do C. Se o número for muito grande para
  caber no tipo de saída, um sinalizador *overflow* será definido e
  retornado ao chamador. (Contribuição de Case Van Horsen; bpo-7528 e
  bpo-7767.)

* Nova função: decorrente da reescrita da conversão string-para-float,
  uma nova função "PyOS_string_to_double()" foi adicionada. As antigas
  funções "PyOS_ascii_strtod()" e "PyOS_ascii_atof()" agora foram
  descontinuadas.

* Nova função: "PySys_SetArgvEx()" define o valor de "sys.argv" e pode
  opcionalmente atualizar "sys.path" para incluir o diretório que
  contém o script nomeado por "sys.argv[0]" dependendo do valor de um
  parâmetro *updatepath*.

  Esta função foi adicionada para fechar uma falha de segurança em
  aplicativos que incorporam Python. A função antiga,
  "PySys_SetArgv()", sempre atualizava "sys.path", e às vezes
  adicionava o diretório atual. Isso significava que, se você
  executasse uma aplicação incorporando Python em um diretório
  controlado por outra pessoa, os invasores poderiam colocar um módulo
  cavalo de Troia no diretório (digamos, um arquivo chamado "os.py")
  que sua aplicação então usaria. importar e executar.

  Se você mantém uma aplicação C/C++ que incorpora Python, verifique
  se está chamando "PySys_SetArgv()" e considere cuidadosamente se a
  aplicação deve usar "PySys_SetArgvEx()" com *updatepath* definido
  como false.

  Problema de segurança relatado como **CVE 2008-5983**; discutido em
  bpo-5753, e corrigido por Antoine Pitrou.

* Novas macros: os arquivos de cabeçalho do Python agora definem as
  seguintes macros: "Py_ISALNUM", "Py_ISALPHA", "Py_ISDIGIT",
  "Py_ISLOWER", "Py_ISSPACE", "Py_ISUPPER", "Py_ISXDIGIT",
  "Py_TOLOWER" e "Py_TOUPPER". Todas essas funções são análogas às
  macros padrão C para classificação de caracteres, mas ignoram a
  configuração de localidade atual, porque em vários lugares o Python
  precisa analisar caracteres de maneira independente de localidade.
  (Adição de Eric Smith; bpo-5793.)

* Função removida: "PyEval_CallObject()" agora está disponível apenas
  como uma macro. Uma versão de função estava sendo mantida para
  preservar a compatibilidade de links ABI, mas isso foi em 1997;
  certamente pode ser excluído agora. (Remoção de Antoine Pitrou;
  bpo-8276.)

* Novos códigos de formato: as funções "PyString_FromFormat()",
  "PyString_FromFormatV()" e "PyErr_Format()" agora aceitam "%lld" e
  "%llu" códigos de formato para exibir os tipos long long de C.
  (Contribuição de Mark Dickinson; bpo-7228.)

* A complicada interação entre threads e forks de processos foi
  alterada. Anteriormente, o processo filho criado por "os.fork()"
  pode falhar porque o filho é criado com apenas um único thread em
  execução, a thread executando "os.fork()". Se outros threads
  estivessem mantendo uma trava, como a trava de importação do Python,
  quando o fork fosse executado, a trava ainda seria marcada como
  "retida" no novo processo. Mas no processo filho nada liberaria a
  trava, pois os outros threads não foram replicados e o processo
  filho não seria mais capaz de realizar importações.

  Python 2.7 adquire a trava de importação antes de executar um
  "os.fork()", e também limpará quaisquer travas criadas usando o
  módulo "threading". Módulos de extensão C que possuem travas
  internas, ou que chamam "fork()" eles próprios, não se beneficiarão
  desta limpeza.

  (Correção de Thomas Wouters; bpo-1590864.)

* A função "Py_Finalize()" agora chama a função interna
  "threading._shutdown()"; isso evita que algumas exceções sejam
  levantadas quando um interpretador é encerrado. (Patch de Adam
  Olsen; bpo-1722344.)

* Ao usar a estrutura "PyMemberDef" para definir atributos de um tipo,
  o Python não permitirá mais que você tente excluir ou definir um
  atributo "T_STRING_INPLACE".

* Símbolos globais definidos pelo módulo "ctypes" agora são prefixados
  com "Py", ou com "_ctypes". (Implementado por Thomas Heller;
  bpo-3102.)

* Nova opção de configuração: a opção "--with-system-expat" permite
  construir o módulo "pyexpat" para usar a biblioteca Expat do
  sistema. (Contribuição de Arfrever Frehtes Taifersar Arahesis;
  bpo-7609.)

* Nova opção de configuração: a opção "--with-valgrind" agora
  desativará o alocador pymalloc, o que é difícil para o detector de
  erros de memória Valgrind analisar corretamente. Valgrind será,
  portanto, melhor na detecção de vazamentos e sobrecargas de memória.
  (Contribuição de James Henstridge; bpo-2422.)

* Nova opção de configuração: agora você pode fornecer uma string
  vazia para "--with-dbmliborder=" para desabilitar todos os vários
  módulos DBM. (Adição de Arfrever Frehtes Taifersar Arahesis;
  bpo-6491.)

* O script **configure** agora verifica bugs de arredondamento de
  ponto flutuante em determinados chips Intel de 32 bits e define uma
  definição de pré-processador "X87_DOUBLE_ROUNDING". Nenhum código
  usa essa definição no momento, mas ela está disponível para quem
  quiser. (Adicionado por Mark Dickinson; bpo-2937.)

  **configure** agora também define uma variável Makefile
  "LDCXXSHARED" para oferecer suporte à ligação C++. (Contribuição de
  Arfrever Frehtes Taifersar Arahesis; bpo-1222585.)

* O processo de construção agora cria os arquivos necessários para
  suporte ao pkg-config. (Contribuição de Clinton Roy; bpo-3585.)

* O processo de construção agora prover suporte ao Subversion 1.7.
  (Contribuição de Arfrever Frehtes Taifersar Arahesis; bpo-6094.)


Capsules
--------

Python 3.1 adiciona um novo tipo de dados C, "PyCapsule", para
fornecer uma API C para um módulo de extensão. Uma cápsula é
essencialmente o detentor de um ponteiro C "void *" e é
disponibilizada como um atributo de módulo; por exemplo, a API do
módulo "socket" é exposta como "socket.CAPI", e "unicodedata" expõe
"ucnhash_CAPI". Outras extensões podem importar o módulo, acessar seu
dicionário para obter o objeto cápsula e então obter o ponteiro "void
*", que normalmente apontará para uma matriz de ponteiros para as
diversas funções da API do módulo.

Já existe um tipo de dados usado para isso, "PyCObject", mas ele não
fornece segurança de tipo. Código maligno escrito em Python puro pode
causar uma falha de segmentação pegando um "PyCObject" do módulo A e
de alguma forma substituindo-o por "PyCObject" no módulo B. As
cápsulas sabem seu próprio nome , e para obter o ponteiro é necessário
fornecer o nome:

   void *vtable;

   if (!PyCapsule_IsValid(capsule, "mymodule.CAPI") {
           PyErr_SetString(PyExc_ValueError, "argument type invalid");
           return NULL;
   }

   vtable = PyCapsule_GetPointer(capsule, "mymodule.CAPI");

Você tem certeza de que "vtable" aponta para o que você espera. Se uma
cápsula diferente fosse passada, "PyCapsule_IsValid()" detectaria o
nome incompatível e retornaria falso. Consulte Fornecendo uma API C
para um módulo de extensão para mais informações sobre como usar esses
objetos.

Python 2.7 agora usa cápsulas internamente para fornecer várias APIs
de módulo de extensão, mas o "PyCObject_AsVoidPtr()" foi modificado
para lidar com cápsulas, preservando a compatibilidade em tempo de
compilação com a interface "PyCObject". O uso de
"PyCObject_AsVoidPtr()" sinalizará uma exceção
"PendingDeprecationWarning", que é silencioso por padrão.

Implementado em Python 3.1 e portado para 2.7 por Larry Hastings;
discutido em bpo-5630.


Alterações específicas da porta: Windows
----------------------------------------

* O módulo "msvcrt" agora contém algumas constantes do arquivo de
  cabeçalho "crtassem.h": "CRT_ASSEMBLY_VERSION",
  "VC_ASSEMBLY_PUBLICKEYTOKEN" e "LIBRARIES_ASSEMBLY_NAME_PREFIX".
  (Contribuição de David Cournapeau; bpo-4365.)

* O módulo "_winreg" para acessar o registro agora implementa as
  funções "CreateKeyEx()" e "DeleteKeyEx()", versões estendidas de
  funções suportadas anteriormente que recebem vários argumentos
  extras. Os "DisableReflectionKey()", "EnableReflectionKey()" e
  "QueryReflectionKey()" também foram testados e documentados.
  (Implementação de Brian Curtin: bpo-7347.)

* A nova API "_beginthreadex()" é usada para iniciar threads, e as
  funções nativas de armazenamento local de thread agora são usadas.
  (Contribuição de Kristján Valur Jónsson; bpo-3582.)

* A função "os.kill()" agora funciona no Windows. O valor do sinal
  pode ser as constantes "CTRL_C_EVENT", "CTRL_BREAK_EVENT" ou
  qualquer número inteiro. As duas primeiras constantes enviarão
  eventos de pressionamento de tecla "Control"-"C" e "Control"-"Break"
  para subprocessos; qualquer outro valor usará a API
  "TerminateProcess()". (Contribuição de Miki Tebeka; bpo-1220212.)

* A função "os.listdir()" agora falha corretamente para um caminho
  vazio. (Correção de Hirokazu Yamamoto; bpo-5913.)

* O módulo "mimetypes" agora irá ler o banco de dados MIME do registro
  do Windows ao inicializar. (Patch de Gabriel Genellina; bpo-4969.)


Alterações específicas da porta: Mac OS X
-----------------------------------------

* O caminho "/Library/Python/2.7/site-packages" agora é anexado a
  "sys.path", para compartilhar pacotes adicionados entre a instalação
  do sistema e uma cópia da mesma versão instalada pelo usuário.
  (Alteração de Ronald Oussoren; bpo-4865.)

  Alterado na versão 2.7.13: A partir da versão 2.7.13, esta alteração
  foi removida. "/Library/Python/2.7/site-packages", o diretório site-
  packages usado pelo sistema Python 2.7 fornecido pela Apple não é
  mais anexado a "sys.path" para Pythons instalados pelo usuário, como
  do Instaladores do python.org. A partir do macOS 10.12, a Apple
  mudou a forma como o diretório site-packages do sistema é
  configurado, o que pode causar falha na instalação de componentes
  pip, como setuptools. Os pacotes instalados para o sistema Python
  não serão mais compartilhados com Pythons instalados pelo usuário. (
  bpo-28440)


Alterações específicas da porta: FreeBSD
----------------------------------------

* Constante "SO_SETFIB" do FreeBSD 7.1, usada com os métodos
  "getsockopt()" e "setsockopt()" do "socket()" para selecionar uma
  tabela de roteamento alternativa, agora está disponível no módulo
  "socket". (Adição de Kyle VanderBeek; bpo-8235.)


Outras alterações e correções
=============================

* Dois scripts de benchmark, "iobench" e "ccbench", foram adicionados
  ao diretório "Tools". "iobench" mede a velocidade dos objetos
  embutidos de E/S de arquivo retornados por "open()" durante a
  execução de várias operações, e "ccbench" é um benchmark de
  simultaneidade que tenta medir o rendimento da computação, latência
  de comutação de threads e largura de banda de processamento de E/S
  ao executar diversas tarefas usando um número variável de threads.

* O script "Tools/i18n/msgfmt.py" agora entende formas plurais em
  arquivos ".po". (Correção de Martin von Löwis; bpo-5464.)

* Ao importar um módulo de um arquivo ".pyc" ou ".pyo" com uma
  contraparte ".py" existente, os atributos "co_filename" dos objetos
  código resultantes são substituídos quando o nome do arquivo
  original fica obsoleto. Isso pode acontecer se o arquivo tiver sido
  renomeado, movido ou acessado por caminhos diferentes. (Patch de
  Ziga Seilnacht e Jean-Paul Calderone; bpo-1180193.)

* O script "regrtest.py" agora usa uma opção "--randseed=" que recebe
  um número inteiro que será usado como semente aleatória para a opção
  "-r" que executa testes em ordem aleatória. A opção "-r" também
  informa a semente que foi usada (Adição de Collin Winter.)

* Outra opção "regrtest.py" é "-j", que recebe um número inteiro
  especificando quantos testes são executados em paralelo. Isto
  permite reduzir o tempo total de execução em máquinas com vários
  núcleos. Esta opção é compatível com várias outras opções, incluindo
  a opção "-R" que é conhecida por produzir longos tempos de execução.
  (Adicionado por Antoine Pitrou, bpo-6152.) Isso também pode ser
  usado com uma nova opção "-F" que executa testes selecionados em um
  loop até que eles falhem. (Adição de Antoine Pitrou; bpo-7312.)

* Quando executado como um script, o módulo "py_compile.py" agora
  aceita "'-'" como argumento, que lerá a entrada padrão para a lista
  de nomes de arquivos a serem compilados. (Contribuição de Piotr
  Ożarowski; bpo-8233.)


Portando para Python 2.7
========================

Esta seção lista as alterações descritas anteriormente e outras
correções de bugs que podem exigir alterações em seu código:

* A função "range()" processa seus argumentos de forma mais
  consistente; agora ele chamará "__int__()" em argumentos que não são
  ponto flutuantes nem inteiros que são fornecidos a ele. (Correção de
  Alexander Belopolsky; bpo-1533.)

* O método string "format()" alterou a precisão padrão usada para
  números de ponto flutuante e complexos de 6 casas decimais para 12,
  o que corresponde à precisão usada por "str()". (Alteração de Eric
  Smith; bpo-5920.)

* Por causa de uma otimização para a instrução "with", os métodos
  especiais "__enter__()" e "__exit__()" devem pertencer ao tipo do
  objeto e não podem ser diretamente anexados ao instância do objeto.
  Isto afeta classes de novo estilo (derivadas de "object") e tipos de
  extensão C. (bpo-6101.)

* Devido a um bug no Python 2.6, o parâmetro *exc_value* para os
  métodos "__exit__()" era frequentemente a representação de string da
  exceção, não uma instância. Isso foi corrigido na versão 2.7, então
  *exc_value* será uma instância conforme esperado. (Correção de
  Florent Xicluna; bpo-7853.)

* Quando um conjunto restrito de atributos foi definido usando
  "__slots__", excluir um atributo não definido não levantaria
  "AttributeError" como seria de esperar. Correção de Benjamin
  Peterson; bpo-7604.)

Na biblioteca padrão:

* Operações com instâncias "datetime" que resultaram em um ano fora do
  intervalo suportado nem sempre levantam "OverflowError". Esses erros
  agora são verificados com mais cuidado e irão levantar a exceção.
  (Relato de Mark Leander, patch de Anand B. Pillai e Alexander
  Belopolsky; bpo-7150.)

* Ao usar instâncias "Decimal" com o método "format()" de uma string,
  o alinhamento padrão era anteriormente o alinhamento à esquerda.
  Isso foi alterado para alinhamento à direita, o que pode alterar a
  saída dos seus programas. (Alteração de Mark Dickinson; bpo-6857.)

  Comparações envolvendo um valor NaN de sinalização (ou "sNAN") agora
  sinalizam "InvalidOperation" em vez de retornar silenciosamente um
  valor verdadeiro ou falso dependendo do operador de comparação.
  Valores silenciosos de NaN (ou "NaN") agora são hasheáveis.
  (Corrigido por Mark Dickinson; bpo-7279.)

* A biblioteca "xml.etree.ElementTree" não escapa mais os caracteres
  de e-comercial e colchetes angulares ao gerar uma instrução de
  processamento XML (que se parece com "<?xml-stylesheet
  href="#style1"?>") ou comentário ( que se parece com "<!-- comment
  -->"). (Patch de Neil Muller; bpo-2746.)

* O método "readline()" dos objetos "StringIO" agora não faz nada
  quando um comprimento negativo é solicitado, como fazem outros
  objetos arquivo ou similares. (bpo-7348).

* O módulo "syslog" agora usará o valor de "sys.argv[0]" como
  identificador em vez do valor padrão anterior de "'python'".
  (Alteração de Sean Reifschneider; bpo-8451.)

* O tratamento de erros padrão do módulo "tarfile" foi alterado, para
  não mais suprimir erros fatais. O nível de erro padrão era
  anteriormente 0, o que significava que os erros resultariam apenas
  na gravação de uma mensagem no log de depuração, mas como o log de
  depuração não está ativado por padrão, esses erros passam
  despercebidos. O nível de erro padrão agora é 1, o que levanta uma
  exceção se houver um erro. (Alteração de Lars Gustäbel; bpo-7357.)

* A função "urlsplit()" do módulo "urlparse" agora lida com esquemas
  de URL desconhecidos de uma forma compatível com **RFC 3986**: se a
  URL estiver no formato ""<alguma_coisa>://..."", o texto antes de
  "://" é tratado como o esquema, mesmo que seja um esquema inventado
  que o módulo não conhece. Essa alteração pode quebrar o código que
  contornava o comportamento antigo. Por exemplo, Python 2.6.4 ou 2.5
  retornará o seguinte:

     >>> import urlparse
     >>> urlparse.urlsplit('invented://host/filename?query')
     ('invented', '', '//host/filename?query', '', '')

  Python 2.7 (e Python 2.6.5) vai retornar:

     >>> import urlparse
     >>> urlparse.urlsplit('invented://host/filename?query')
     ('invented', 'host', '/filename?query', '', '')

  (Na verdade, o Python 2.7 produz uma saída ligeiramente diferente,
  pois retorna uma tupla nomeada em vez de uma tupla padrão.)

Para extensões C:

* Extensões C que usam códigos de formato inteiro com a família de
  funções "PyArg_Parse*" agora levantarão uma exceção "TypeError" em
  vez de disparar uma "DeprecationWarning" (bpo-5080).

* Use a nova função "PyOS_string_to_double()" em vez das antigas
  funções "PyOS_ascii_strtod()" e "PyOS_ascii_atof()", que agora estão
  descontinuadas.

Para aplicações que incorporam Python:

* A função "PySys_SetArgvEx()" foi adicionada, permitindo que
  aplicativos fechem uma falha de segurança quando a função
  "PySys_SetArgv()" existente for usada. Verifique se você está
  chamando "PySys_SetArgv()" e considere cuidadosamente se a aplicação
  deve usar "PySys_SetArgvEx()" com *updatepath* definido como falso.


Novos recursos adicionados às versões de manutenção do Python 2.7
=================================================================

Novos recursos podem ser adicionados às versões de manutenção do
Python 2.7 quando a situação realmente exigir. Quaisquer adições devem
passar pelo processo de proposta de melhoria do Python, ou em inglês
Python Enhancement Proposal -- PEP, e apresentar um argumento
convincente sobre por que não podem ser abordadas adequadamente
adicionando o novo recurso apenas ao Python 3 ou publicando-o no
Python Package Index.

Além das propostas específicas listadas abaixo, há uma isenção geral
que permite que novos avisos "-3" sejam adicionados em qualquer versão
de manutenção do Python 2.7.


Duas novas variáveis de ambiente para modo de depuração
-------------------------------------------------------

No modo de depuração, a estatística "[xxx refs]" não é escrita por
padrão, a variável de ambiente "PYTHONSHOWREFCOUNT" agora também deve
ser definida. (Contribuição de Victor Stinner; bpo-31733.)

Quando Python é compilado com "COUNT_ALLOC" definido, as contagens de
alocação não são mais despejadas por padrão: a variável de ambiente
"PYTHONSHOWALLOCCOUNT" agora também deve ser definida. Além disso, as
contagens de alocação agora são despejadas no stderr, em vez do
stdout. (Contribuição de Victor Stinner; bpo-31692.)

Adicionado na versão 2.7.15.


PEP 434: Exceção de aprimoramento do IDLE para todos os branches
----------------------------------------------------------------

**PEP 434** descreve uma isenção geral para alterações feitas no
ambiente de desenvolvimento IDLE enviado junto com o Python. Esta
isenção permite que os desenvolvedores de IDLE forneçam uma
experiência de usuário mais consistente em todas as versões suportadas
do Python 2 e 3.

Para obter detalhes sobre quaisquer alterações do IDLE, consulte o
arquivo NEWS da versão específica.


PEP 466: Aprimoramentos de segurança de rede do Python 2.7
----------------------------------------------------------

**PEP 466** descreve uma série de propostas de melhoria de segurança
de rede que foram aprovadas para inclusão nas versões de manutenção do
Python 2.7, com a primeira dessas mudanças aparecendo na versão Python
2.7.7.

Recursos relacionados a **PEP 466** adicionados no Python 2.7.7:

* "hmac.compare_digest()" foi portado do Python 3 para disponibilizar
  uma operação de comparação resistente a ataques de tempo para
  aplicações em Python 2. (Contribuição de Alex Gaynor; bpo-21306.)

* OpenSSL 1.0.1g foi atualizado nos instaladores oficiais do Windows
  publicados em python.org. (Contribuição de Zachary Ware; bpo-21462.)

Recursos relacionados a **PEP 466** adicionados no Python 2.7.8:

* "hashlib.pbkdf2_hmac()" foi portado do Python 3 para tornar um
  algoritmo de hash adequado para armazenamento seguro de senhas
  amplamente disponível para aplicações Python 2. (Contribuição de
  Alex Gaynor; bpo-21304.)

* OpenSSL 1.0.1h foi atualizado para os instaladores oficiais do
  Windows publicados em python.org. (Contribuição de Zachary Ware em
  bpo-21671 para **CVE 2014-0224**.)

Recursos relacionados a **PEP 466** adicionados no Python 2.7.9:

* A maior parte do módulo "ssl" do Python 3.4 foi portada. Isso
  significa que "ssl" agora provê suporte a indicar de nome de
  servidor, configurações TLS1.x, acesso ao armazenamento de
  certificados da plataforma, a classe "SSLContext" e outros recursos.
  (Contribuição de Alex Gaynor e David Reid; bpo-21308.)

  Consulte as notas "Versão adicionada: 2.7.9" na documentação do
  módulo para obter detalhes específicos.

* "os.urandom()" foi alterado para armazenar em cache um descritor de
  arquivo para "/dev/urandom" em vez de reabrir "/dev/urandom" em cada
  chamada. (Contribuição de Alex Gaynor; bpo-21305.)

* "hashlib.algorithms_guaranteed" e "hashlib.algorithms_available"
  foram portados do Python 3 para tornar mais fácil para os aplicações
  Python 2 selecionarem o algoritmo de hash mais forte disponível.
  (Contribuição de Alex Gaynor em bpo-21307)


PEP 477: Backport do ensurepip (PEP 453) para o Python 2.7
----------------------------------------------------------

A **PEP 477** aprova a inclusão do módulo ensurepip do **PEP 453** e
da documentação aprimorada que foi habilitada por ele nas versões de
manutenção do Python 2.7, aparecendo primeiro na versão Python 2.7.9.


Inicializando pip por padrão
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

O novo módulo "ensurepip" (definido em **PEP 453**) fornece um
mecanismo padrão de plataforma cruzada para inicializar o instalador
pip em instalações Python. A versão do "pip" incluída no Python 2.7.9
é "pip" 1.5.6, e futuras versões de manutenção 2.7.x atualizarão a
versão empacotada para a versão mais recente do "pip" que está
disponível em o momento da criação do candidato a lançamento.

Por padrão, os comandos "pip", "pipX" e "pipX.Y" serão instalados em
todas as plataformas (onde X.Y representa a versão da instalação do
Python), junto com o pacote Python via "pip" e suas dependências.

Para construções de fontes do CPython em sistemas POSIX, os comandos
"make install" e "make altinstall" não inicializam "pip" por padrão.
Este comportamento pode ser controlado através de opções de
configuração e substituído através de opções do Makefile.

No Windows e Mac OS X, os instaladores do CPython agora instalam o
"pip" junto com o próprio CPython (os usuários podem optar por não
instalá-lo durante o processo de instalação). Os usuários do Windows
precisarão optar pelas modificações automáticas do "PATH" para ter o
"pip" disponível na linha de comando por padrão, caso contrário ele
ainda poderá ser acessado através do iniciador Python para Windows
como "py -m pip".

Como **discutido na PEP**, os empacotadores de plataforma podem optar
por não instalar estes comandos por padrão, desde que, quando
invocados, forneçam instruções claras e simples sobre como instalá-los
naquela plataforma (geralmente usando o gerenciador de pacotes do
sistema). .


Mudanças na documentação
~~~~~~~~~~~~~~~~~~~~~~~~

Como parte desta mudança, as seções Instalando módulos Python e
Distribuindo módulos Python da documentação foram completamente
redesenhadas como breves documentos de introdução e FAQ. A maior parte
da documentação de empacotamento agora foi transferida para o Python
Packaging Authority, mantido no Guia de Usuário para Empacotamento de
Python e na documentação dos projetos individuais.

No entanto, como esta migração ainda está incompleta, as versões
legadas desses guias permanecem disponíveis como Construindo extensões
C e C ++ com setuptools e Construindo extensões C e C ++ com
setuptools.

Ver também:

  **PEP 453** -- Inicialização explícita do pip em instalações Python
     PEP escrita por Donald Stufft e Nick Coghlan, implementada por
     Donald Stufft, Nick Coghlan, Martin von Löwis e Ned Deily.


PEP 476: Habilitando verificação de certificado por padrão para clientes http stdlib
------------------------------------------------------------------------------------

**PEP 476** atualizou "httplib" e módulos que o utilizam, como
"urllib2" e "xmlrpclib", para agora verificar se o servidor apresenta
um certificado que é assinado por uma Autoridade Certificadora no
armazenamento confiável da plataforma e cujo nome de host corresponde
ao nome de host solicitado por padrão, melhorando significativamente a
segurança para muitas aplicações. Essa alteração foi feita na versão
2.7.9 do Python.

Para aplicações que exigem o antigo comportamento anterior, elas podem
passar um contexto alternativo:

   import urllib2
   import ssl

   # Isso desabilita toda verificação
   context = ssl._create_unverified_context()

   # Isso permite usar um certificado específico para o host,
   # o que não precisa ser no armazenamento de confiança
   context = ssl.create_default_context(cafile="/path/to/file.crt")

   urllib2.urlopen("https://invalid-cert", context=context)


PEP 493: Ferramentas de migração de verificação HTTPS para Python 2.7
---------------------------------------------------------------------

**PEP 493** fornece ferramentas de migração adicionais para provê um
processo de atualização de infraestrutura mais incremental para
ambientes contendo aplicações e serviços que dependem do processamento
historicamente permissivo de certificados de servidor ao estabelecer
conexões HTTPS de clientes. Essas adições foram feitas na versão
2.7.12 do Python.

Estas ferramentas destinam-se a ser utilizadas em casos em que as
aplicações e serviços afetados não podem ser modificados para passar
explicitamente um contexto SSL mais permissivo ao estabelecer a
ligação.

Para aplicações e serviços que não podem ser modificados, a nova
variável de ambiente "PYTHONHTTPSVERIFY" pode ser definida como "0"
para reverter todo um processo Python de volta ao comportamento
permissivo padrão do Python 2.7.8 e anteriores.

Para casos em que o código de estabelecimento da conexão não pode ser
modificado, mas a aplicação geral pode, a nova função
"ssl._https_verify_certificates()" pode ser usada para ajustar o
comportamento padrão em tempo de execução.


Novo alvo de construção "make regen-all"
----------------------------------------

Para simplificar a compilação cruzada e garantir que o CPython possa
ser compilado de forma confiável sem exigir que uma versão existente
do Python já esteja disponível, o sistema de construção baseado em
autotools não tenta mais recompilar implicitamente os arquivos gerados
com base nos tempos de modificação dos arquivos.

Em vez disso, um novo comando "make regen-all" foi adicionado para
forçar a regeneração desses arquivos quando desejado (por exemplo,
após uma versão inicial do Python já ter sido construída com base nas
versões pré-geradas).

Alvos de regeneração mais seletivos também são definidos -- veja
Makefile.pre.in para detalhes.

(Contribuição de Victor Stinner em bpo-23404.)

Adicionado na versão 2.7.14.


Remoção do alvo de construção "make touch"
------------------------------------------

O alvo de construção "make touch" usado anteriormente para solicitar
regeneração implícita de arquivos gerados atualizando seus tempos de
modificação foi removido.

Ele foi substituído pelo novo alvo "make regen-all".

(Contribuição de Victor Stinner em bpo-23404.)

Alterado na versão 2.7.14.


Reconhecimentos
===============

O autor gostaria de agradecer às seguintes pessoas por oferecerem
sugestões, correções e assistência com vários rascunhos deste artigo:
Nick Coghlan, Philip Jenvey, Ryan Lovett, R. David Murray, Hugh
Secker-Walker.
