O que há de novo no Python 3.0

Autor:

Guido van Rossum

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

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

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

Obstáculos comuns

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

Visualizações e iteradores em vez de listas

Algumas APIs conhecidas não retornam mais listas:

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

  • Also, the dict.iterkeys(), dict.iteritems() and dict.itervalues() methods are no longer supported.

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

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

  • range() now behaves like xrange() used to behave, except it works with values of arbitrary size. The latter no longer exists.

  • zip() agora retorna um iterador.

Comparações de ordenação

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

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

  • sorted() and list.sort() no longer accept the cmp argument providing a comparison function. Use the key argument instead. N.B. the key and reverse arguments are now “keyword-only”.

  • The cmp() function should be treated as gone, and the __cmp__() special method is no longer supported. Use __lt__() for sorting, __eq__() with __hash__(), and other rich comparisons as needed. (If you really need the cmp() functionality, you could use the expression (a > b) - (a < b) as the equivalent for cmp(a, b).)

Inteiros

  • PEP 237: Essentially, long renamed to int. That is, there is only one built-in integral type, named int; but it behaves mostly like the old long type.

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

  • The sys.maxint constant was removed, since there is no longer a limit to the value of integers. However, sys.maxsize can be used as an integer larger than any practical list or string index. It conforms to the implementation’s “natural” integer size and is typically the same as sys.maxint in previous releases on the same platform (assuming the same build options).

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

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

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

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

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

  • As a consequence of this change in philosophy, pretty much all code that uses Unicode, encodings or binary data most likely has to change. The change is for the better, as in the 2.x world there were numerous bugs having to do with mixing encoded and unencoded text. To be prepared in Python 2.x, start using unicode for all unencoded text, and str for binary or encoded data only. Then the 2to3 tool will do most of the work for you.

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

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

  • Like str, the bytes type is immutable. There is a separate mutable type to hold buffered binary data, bytearray. Nearly all APIs that accept bytes also accept bytearray. The mutable API is based on collections.MutableSequence.

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

  • The built-in basestring abstract type was removed. Use str instead. The str and bytes types don’t have functionality enough in common to warrant a shared base class. The 2to3 tool (see below) replaces every occurrence of basestring with str.

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

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

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

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

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

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

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

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

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

Visão geral das alterações da sintaxe

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

Nova sintaxe

  • PEP 3107: Function argument and return value annotations. This provides a standardized way of annotating a function’s parameters and return value. There are no semantics attached to such annotations except that they can be introspected at runtime using the __annotations__ attribute. The intent is to encourage experimentation through metaclasses, decorators or frameworks.

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

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

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

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

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

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

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

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

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

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

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

Sintaxe alterada

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

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

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

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

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

    class C:
    __metaclass__ = M
    ...

    agora você deve usar:

    class C(metaclass=M):
    ...

    The module-global __metaclass__ variable is no longer supported. (It was a crutch to make it easier to default to new-style classes without deriving every class from object.)

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

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

Sintaxe removida

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

  • Removidos backticks (use repr()).

  • Removido <> (use !=).

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

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

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

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

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

  • As classes clássicas se foram.

Mudanças já presentes no Python 2.6

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

Mudanças na biblioteca

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

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

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

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

    Old Name

    Novo nome

    _winreg

    winreg

    ConfigParser

    configparser

    copy_reg

    copyreg

    Queue

    queue

    SocketServer

    socketserver

    markupbase

    _markupbase

    repr

    reprlib

    test.test_support

    test.support

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

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

    • dbm (anydbm, dbhash, dbm, dumbdbm, gdbm, whichdb).

    • html (HTMLParser, htmlentitydefs).

    • http (httplib, BaseHTTPServer, CGIHTTPServer, SimpleHTTPServer, Cookie, cookielib).

    • tkinter (all Tkinter-related modules except turtle). The target audience of turtle doesn’t really care about tkinter. Also note that as of Python 2.6, the functionality of turtle has been greatly enhanced.

    • urllib (urllib, urllib2, urlparse, robotparse).

    • xmlrpc (xmlrpclib, DocXMLRPCServer, SimpleXMLRPCServer).

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

  • sets eliminado. Use a classe embutida set().

  • Cleanup of the sys module: removed sys.exitfunc(), sys.exc_clear(), sys.exc_type, sys.exc_value, sys.exc_traceback. (Note that sys.last_type etc. remain.)

  • Cleanup of the array.array type: the read() and write() methods are gone; use fromfile() and tofile() instead. Also, the 'c' typecode for array is gone – use either 'b' for bytes or 'u' for Unicode characters.

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

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

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

  • O módulo new foi removido.

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

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

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

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

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

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

Mudanças para exceções

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

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

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

  • StandardError was removed.

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

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

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

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

    raise SecondaryException() from primary_exception

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

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

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

Outras mudanças diversas

Operadores e métodos especiais

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

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

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

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

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

  • Removed support for __members__ and __methods__.

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

  • __nonzero__() agora é __bool__().

Funções embutidas

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

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

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

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

  • Moved intern() to sys.intern().

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

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

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

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

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

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

  • Removed reload(). Use imp.reload().

  • Removed. dict.has_key() – use the in operator instead.

Mudanças a construções e API C

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

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

  • PEP 3118: Nova API de Buffer.

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

  • PEP 3123: Tornando PyObject_HEAD conforme o padrão C.

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

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

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

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

  • Removidas METH_OLDARGS e WITH_CYCLE_GC da API C.

Desempenho

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

Portando para o Python 3.0

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

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

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

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

  4. Execute o tradutor de fonte para fonte 2to3 sobre sua árvore de código-fonte. (Veja 2to3 — Tradução Automatizada de Código Python 2 para 3 para mais informações sobre esta ferramenta.) Execute o resultado da tradução no Python 3.0. Corrija manualmente quaisquer problemas restantes, corrigindo os problemas até que todos os testes passem novamente.

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

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