Este documento fornece uma visão geral das principais mudanças que serão introduzidas no Python 3000, como correções de erros antigos e adição de novas funcionalidades que quebrariam a compatibilidade com versões anteriores. Ele também discute ferramentas que serão criadas para ajudar na migração e fornece dicas para evitar problemas de compatibilidade futuros.
2. Disclaimer
Antes de montar essa apresentação o próprio GvR fez uma
apresentação sobre Python-3000
Apresentação focada nas mudanças
http://www.python.org/doc/essays/ppt/accu2006/Py3kACCU.ppt
Essa apresentação foca na preparação para a migração
3. Python 3000
Python 3000 == Py3k == Python 3.0
Não vai ser uma nova linguagem!
A idéia principal:
Corrigir erros do passado!
Compatibilidade retroativa não será uma preocupação
Código feito para Python certamente vai quebrar
Funcionalidades interessantes poderão ser adicionadas
Aquelas que certamente causariam quebra de compatibilidade
Se não quebra compatibilidade podem ser adicionadas ainda na
série 2.x
4. Quando?
Neste momento está sendo discutido o processo de
desenvolvimento do Py3k.
Cuidados especiais:
Não transformar o Py3k no novo Perl6
Rejeitar propostas inviáveis rapidamente para não desperdiçar
tempo
Cronograma prévio:
Primeiro Alpha: não menos de 1 ano
Primeiro Beta: provavelmente um ano depois do Alpha
Releases 3.1, 3.2, ... lançados imediatamente após
5. PEPs 3000
PEP 3000 – Python 3000
PEP 3001 – Revisão e melhoria da biblioteca padrão
PEP 3003 – Como lidar com mudança que causa
incompatibilidade
PEP 3099 – O que não vão mudar
PEP 3100 – Lista de mudanças que serão avaliadas
Algumas mudanças já são praticamente certas
PEP 3101 – Formatação avançada de strings
Porque isso está aqui? Não poderia ser adicionado no Python 2.x?
Sintaxe muito semelhante à usada no C#
PEP 3102 – Parâmetro obrigatoriamente passado por
keyword
6. E o Python 2?
Continua o desenvolvimento!
Será mantido até que o Python 3 tenha atingido um alto
grau de maturidade
Funcionalidades do Py3k serão aplicadas à versão 2 sempre que
possível
Plano de releases cobre as versões 2.6, 2.7, 2.8 e 2.9
Mais informações na PEP 3000
7. Incompatibilidade?
Uma visão geral das incompatibilidades
previstas:
Novas keywords poderão ser criadas
dict.keys(), range(), zip() retornarão iteradores (e
métodos complementares a esses, que retornam
iteradores, sumirão)
Todas as strings serão Unicode
Redesenho do sistema de I/O
Remoção de funções builtin substituíveis por list
compreensions
Funcionalidades deprecated removidas
● ex. Old-style classes
8. Apoio na migração
Ferramentas serão criadas para ajudar na migração
Scripts para conversão (sempre que possível)
Será possível ligar warnings para código incompatível com o
py3k no Python 2
Facilidade de migração é um fator levado em alta consideração no
processo da criação do Py3k
Ferramentas como pychecker poderão avisar quando algo pode
apresentar problema de compatibilidade
Mais informações nas PEPs 3003, 3099, 3100
9. Evitando problemas futuros
Já é possível se prevenir de problemas de compatibilidade
com o Python 3 desde já
Muitas dicas podem não servir para nada futuramente :)
10. Dicas Genéricas
Repetindo: evite construções que já estão marcadas como
candidatas à 'morte'.
Sempre que precisar usá-las lembre-se de sinalizar o
trecho onde isso ocorre
Evite alguns nomes de variáveis que possam se tornar
palavras reservadas (ex. preposições em inglês como “as”)
List comprehensions e Generator Expressions são suas
amigas, use-as!
11. Linguagem
Fuja do comando exec
Sumirá na forma de comando. Talvez se torne uma função
Comando print
Passará a ser uma função
Evite usar a sintaxe “>>xx”, prefira usar xx.write()
Evite usar “,” para suprimir a quebra de linha (ex. print
“spam”,)
Use != no lugar de <>
Evite exceções string
Use raise Exception(“spam”) no lugar de raise Exception,
“spam”
12. Linguagem
Use repr(x) no lugar de `x`
Use o operador in no lugar de dict.has_key()
Cuidado com funções que retornam lists, elas podem
começar a retornar iterators
Use inteiro1//inteiro2 no lugar de inteiro1/inteiro2
Remova tudo o que emite “DeprecationWarning”
13. Old-style Classes
Todas as classes serão do tipo new-style, mesmo aquelas
que não herdam de object
Mas as que herdam de object continuarão sendo new-
style classes, logo, desde hoje tente fazer: class
Spam(object): ... no lugar de class Spam: ...
Não está claro ainda se os métodos __(get|set)attr__
desaparecerão (já que em new-style classes é preferível
usar __(get|set)attribute__)
Minha suspeita é a de que não desaparecerão por se tratarem de
métodos usados com propósitos ligeiramente diferentes
14. Builtins
Saem:
apply() -> f(*args, **kw)
buffer()
callable() -> try/except
compile() -> passa para o módulo sys
coerce()
execfile(), reload() -> exec()
input() -> eval(sys.stdin.readline())
id() -> passa para o módulo sys
intern() -> passa para o módulo sys
map(), filter() -> list comprehension
raw_input() -> sys.stdin.readline()
xrange() -> range()
15. Builtins
Surgem:
exec() -> comando exec
print() -> comando print
byte() -> antiga classe 'str'
Mudam:
range(), zip() -> iterator no lugar de list
min(), max(), sum() -> tratarão iterators
Hierarquia das exceptions
16. Acompanhe o desenvolvimento
Leias as PEPs 3000
http://www.python.org/peps/
Assine a lista: python-3000@python.org
http://www.python.org/mailman/listinfo/
Acompanhe o blog do GvR
http://artima.com/weblogs/