>>> round(1.2)
1
>>> round(1.8)
2

Ela ainda aceita um segundo parâmetro, que indica quantos dígitos de precisão queremos no resultado. O valor padrão desse parâmetro é 0, mas podemos passar qualquer valor:

>>> round(1.847, ndigits=2)
1.85
>>> round(1.847, ndigits=1)
1.8

E o que será que acontece quando queremos arredondar um número como 1.5? A round() arredonda pra cima ou pra baixo? Vamos ver:

>>> round(1.5)
2

Arredonda pra cima? Vamos ver mais um número só pra ter certeza:

>>> round(2.5)
2

Ops, agora foi pra baixo! Vamos ver mais alguns:

>>> round(3.5)
4
>>> round(4.5)
4
>>> round(5.5)
6

Calma aí que tudo tem uma explicação. Em Python 3, a round() define o arredondamento assim:

Arredonda pro mais próximo.
Se empatar, arredonda pro número PAR mais próximo.

Agora faz sentido né? Revendo os exemplos dali de cima, vemos que o arredondamento sempre foi feito pro par mais próximo:

>>> round(3.5)
4
>>> round(4.5)
4
>>> round(5.5)
6

No caso do 3.5, tanto o 3 quanto o 4 estão à mesma distância dele. Ou seja, deu empate. Como a regra determina, round() desempata pro par mais próximo, que é 4.

E em Python 2?

Em Python 2 é diferente. O empate em arredondamentos é sempre resolvido pra cima, em caso de números positivos:

>>> round(1.5)
2.0
>>> round(2.5)
3.0

E pra baixo, em caso de números negativos:

>>> round(-1.5)
-2.0
>>> round(-2.5)
-3.0

Mas por que Python 3 faz diferente?

O objetivo é deixar o arredondamento menos tendencioso.

Imagine um banco onde todos os arredondamentos são feitos para cima. Ao final do dia, o relatório de receitas do banco vai mostrar um valor mais alto do que o banco realmente recebeu. É exatamente o que acontece em Python 2:

>>> valores = [1.5, 2.5, 3.5, 4.5]
>>> sum(valores)
12.0
>>> sum(round(v) for v in valores)
14.0

Usando a regra de arredondamento de Python 3, os valores arredondados nas operações tendem a ser amortizados, porque metade deles vai ser para cima e a outra metade para baixo, visto que metade dos números existente são pares e a outra metade são ímpares. Veja o mesmo código, agora rodando em Python 3:

>>> valores = [1.5, 2.5, 3.5, 4.5]
>>> sum(valores)
12.0
>>> sum(round(v) for v in valores)
12

Na realidade, isso não é uma novidade de Python 3. Esse tipo de arredondamento é antigo e tem até nome: Bankers Rounding (Arredondamento de Banqueiros).

Se ficou interessado no assunto, dê uma olhada num outro post daqui do blog, que mostra como funciona a divisão inteira em Python: https://pythonhelp.wordpress.com/2013/06/30/comportamento-inesperado-na-divisao-inteira/

print("Hello, world!")

Muita gente, quando pensa em mudar pro Python 3, já lembra de cara dessa diferença. Mas, existem várias outras mudanças que são bem importantes. Vou listar aqui as que considero que vão ter maior impacto na maioria dos programadores.

Operador de divisão inteira

A partir do Python 3, 3/2 resulta em 1.5, e não mais em 1. Ou seja, o operador / não é mais dependente dos tipos dos operados. No Python 2.x, o resultado de uma divisão de dois números inteiros era também um número inteiro, arredondado para baixo, sempre.

O operador // foi inserido no Python 3 para representar a divisão inteira. Assim, podemos ver alguns exemplos abaixo:

>>> 3 / 2
1.5
>>> 3 // 2
1
>>> -3 // 2
-2

(se você ficou confuso com o resultado da última expressão, clique aqui e entenda o porquê)

Assim, programas Python 2.x que dependiam do arredondamento do operador /, não irão mais funcionar corretamente na versão 3.x. Fique de olho!

True, False agora são palavras reservadas (finalmente!)

Em Python 2.x, era possível fazermos coisas bizarras como:

>>> True = "Hello"
>>> False = "Hello"
>>> True == False
True

Ou então, tão estranho quanto:

>>> False = True
>>> True == False
True

Felizmente, em Python 3 isso não é mais possível. Veja uma tentativa:

>>> True = "Hello"
SyntaxError: assignment to keyword

xrange() se foi

A função xrange() deixou de existir no Python 3. Lembra que, no Python 2, range() retornava uma lista e xrange() retornava um objeto iterável? O impacto disso era que, para grandes sequências numéricas, xrange() acabava sendo mais eficiente do que range(), pois usava muito menos espaço em memória para gerar a sequência (leia mais aqui).

No Python 3, só existe a função range(), que retorna uma espécie de iterável (assim como xrange() fazia).

map, filter e zip também mudaram

As funções map, filter e zip, assim como range(), também retornavam uma lista com os valores de resultado. A partir do Python 3, elas passaram a retornar objetos iteráveis, ao invés de gerar listas enormes em memória. Isso impacta bastante em código Python 2.x, visto que coisas simples deixam de funcionar, como o exemplo abaixo:

>>> len(map(lambda x: x*x, [1, 2, 3]))
TypeError: object of type 'map' has no len()

Isso pode ser corrigido com uma “conversão” do iterável retornado pelo map() para lista:

>>> len(list(map(lambda x: x*x, [1,2,3])))
3

E o mesmo vale para as funções zip e filter também. Ah, outra mudança forte é que a função reduce() foi “rebaixada” para o módulo functools, deixando de ser uma função global do Python.

has_key não existe mais nos dicionários

Em Python 2.x, era comum verificar se um determinado elemento já era chave em um dicionário usando o método has_key():

>>> d = {'nome': 'jose', 'idade': 18}
>>> d.has_key('nome')
True
>>> d.has_key('email')
False

Em Python 3.x, para fazer a mesma verificação, usamos o operador in:

>>> 'nome' in d
True
>>> 'email' in d
False

Ainda falando sobre dicionários, os métodos que em Python 2.x retornavam listas, agora retornam espécies de iteráveis (na verdade, são views dinâmicas, sobre as quais pretendo falar em um próximo post).

Toda string é unicode

Em Python 3.x, só existe um tipo de String: as strings unicode. Assim, não é mais preciso especificar em uma string literal que ela é do tipo unicode. Em Python 2.x, um literal unicode era declarado como:

>>> string_unicode = u"olá mundo"

(repare no ‘u’ precedendo o literal)

Em Python 3.x, isso não é preciso, pois toda string é unicode:

>>> string_unicode = "olá mundo"

Agora só existe input()

Em Python 2.x, existiam duas funções para fazer a leitura de valores do teclado: input() e raw_input(). A primeira lia expressões Python e as executava e a segunda lia strings.

Em Python 3.x, só existe uma função: input(). Ela lê uma string do teclado, que então pode ser convertida para o tipo apropriado. Por exemplo, para ler um valor numérico inteiro:

>>> idade = int(input('Digite sua idade:'))
Digite sua idade:10
>>> type(idade)
int

Por fim…

Além das modificações apresentadas acima, foram feitas inúmeras outras, principalmente na reestruturação de bibliotecas, deixando-as com interfaces mais consistentes. Até agora, achei muito interessantes as alterações feitas da versão 2 para a 3, pois elas deixaram tudo mais Pythônico e consistente.

Para portar aquele seu programa escrito usando Python 2 para Python 3, foi criada uma ferramenta bem interessante chamada de 2to3, que pega seu código legado e o transforma em código compatível com a versão 3 da linguagem. É claro que ela não faz milagre e, na maioria dos casos, é preciso intervenção manual. Mas já é uma ajuda para códigos mais simples.

Por exemplo, o programa hello.py:

print "hello, world!"

Pode ser convertido usando o 2to3:

$ 2to3 -w hello.py

O resultado é o programa hello.py, agora pronto pra versão 3:

print("hello, world!")

Leia mais

• http://docs.python.org/2/library/2to3.html
• http://www.diveinto.org/python3/
• http://www.diveinto.org/python3/porting-code-to-python-3-with-2to3.html