A edição do Language Summit 2011 aconteceu no dia 10 de março em Atlanta, dia
anterior ao início da PyCon 2011. Desenvolvedores de CPython, PyPy, Jython,
IronPython, e Parrot VMs; mantenedores de distribuições Linux Fedora, Ubuntu, e Debian;
desenvolvedores do projecto Twisted, dentre outros, estiveram presentes.
Blog dos Desenvolvedores
A primeira ordem do dia foi a discussão a respeito deste blog, desenvolvido pelo
Diretor de Comunicações da PSF, Doug Hellmann. Devido ao grande número de mensagens e
da usual "intensidade" das mensagens da lista Python-Dev, espera-se que o blog seja
uma maneira mais fácil e direta de se obter notícias sobre o desenvolvimento da linguagem.
Nós planejamos cobrir as PEPs, decisões importantes, novos recursos e correções críticas de bugs,
incluindo uma cobertura informal do que acontece no desenvolvimento do Python core.
Qualquer implementação de Python poderá postar no Insider. Por exemplo, mesmo que
PyPy já tenha um blog em atividade, os seus desenvolvedores
são bem-vindos para postar aqui. Implementações de Python alternativas serão incluídas na página de download da
python.org, graças a discussões em paralelo. Novas versões também serão anunciadas
na página inicial em python.org.
Avisos de Compatibilidade
Na versão 3.2, introduzimos o ResourceWarning, permitindo que os usuários
encontrem seções de código que dependam da contagem de referências do CPython.
Este aviso não só ajuda os programadores a escrever um código melhor, como também
permite com que escrevam códigos que possam rodar em diferentes VMs de maneira segura.
Para aperfeiçoar a compatibilidade intra-VMs, foi sugerido um novo tipo de aviso:
CompatibilityWarning.
A ideia surgiu de um bug no CPython relatado pelos desenvolvedores de PyPy.
No Issue #11455 é mostrado um problema
onde CPython permite que um usuário crie um type com chaves que não são strings no
__dict__, não suportado por PyPy e Jython. De maneira simples, usuários poderão
ativar um sistema de avisos que detecta casos assim, da mesma forma que o ResourceWarning
é ativado.
Biblioteca Padrão Autônoma
Com o término da mudança do código fonte de Python do Subversion para o Mercurial,
foi novamente aventada a possibilidade de se criar um repositório para abrigar a
biblioteca padrão (standard library). Desenvolvedores das implementações alternativas
parecem bem interessados nessa mudança, o que simplificaria muito o desenvolvimento
dessas versões. O processo atual requer um snapshot de CPython, seguido da aplicação de
patches específicos, substituição de extensões de C por versões nativas de Python, etc.
Esta conversão terá de ser detalhada em uma nova PEP, e um dos pontos de discussão
será a maneira de se acertar o controle de versões. Como a biblioteca ficará independente
de todas as implementações ela terá um versionamento próprio, o que terá de ser
considerado na aplicação de testes.
Um outro tópico no desmembramento da biblioteca padrão são relacionados com as
implementações que utilizam Python puro e suas extensões em C. Maciej Fijalkowski,
do projeto PyPy, mencionou que ao longo do tempo alguns módulos apresentam diferenças
entre as implementações Python e C. Com o início e o desenrolar das discussões, foi sugerida
uma abordagem mais estrita para a mudança desse módulos, evitando-se problemas no uso de
uma das versões de diferentes linguagens. No final, decidiu-se por implementações em Python puro,
sendo que somente no caso de um ganho de velocidade de execução, implementações em C serão criadas.
Página da Velocidade de Execução
O Centro de Velocidade do PyPy (PyPy Speed Center) desenvolveu uma bela amostragem
dos ganhos de velocidade de execução do PyPy, o que levantou o assunto de se criar
algo semelhante na página python.org, mais especificamente no endereço performance.python.org,
para que todas a VMs possam participar. Além de testes de velocidade (benchmarking), poderão ser
incluídos testes de uso de memória, testes passados e compatibilidade de linguagem. Como
atualmente a comparação é feita entre PyPy e CPython, a adaptação da infraestrutura de testes
para que funcione com todas as implementações de Python levará um pouco de tempo.
Foi sugerido a alocação de algumas máquinas de alta capacidade (high-performance) no
Open Source Lab da Oregon State University, no qual
Allison Randal é parte do quadro de administração, criando-se o novo Speed Center. Jesse Noller
mencionou os esforços em se adquirir equipamentos - doações bem-vindas!
Se você ou sua organização estiverem interessados em fazer uma doação, por favor entre em
contato com a Python Software Foundation e acesse a
página de doações.
Término da Moratória
Com o inicio do desenvolvimento da versão 3.3 do CPython, a moratória para mudanças na
linguagem foi terminada. Com a abertura das comportas, espera-se que mudanças na linguagem
sejam mais conservadoras, enquanto se tenta diminuir o ritmo de mudanças, permitindo que
as implementações alternativas estejam no mesmo estágio de desenvolvimento. Embora nenhuma
implementação alternativa tenha alcançado a versões 3.x, graças a moratória, PyPy e IronPython
recentemente alcançaram compatibilidade com a versão 2.7, com IronPython iniciando a trajetória
da versões 3.x.
Com relação a mudanças na linguagem na versão 3.3, fiquem atentos a PEP 380,
a qual já foi aceita. Esta PEP introduz uma nova sintaxe yield from <expr>, permitindo que
o generator yield um outro generator. À exceção disso, nenhuma outra mudança na linguagem é esperada.
Atributos de exceções
O assunto seguinte foi uma breve discussão a respeito de exceções fornecerem atributos mais claros,
ao invés de forçar os usuários depender de mensagens do tipo string. Por exemplo, em um ImportError,
seria mais útil ter acesso a qual método de importação falhou, do que ter de analisar o código
para se identificar a mensagem culpada pelo erro.
Tal implementação deverá depender de argumentos baseados em palavras-chave, quando da inicialização de
objetos de exceção, sendo que um patch já existe para o caso do ImportError.
Acordos de contribuição
Acordos de contribuição também foram mencionados, sendo que um formato eletrônico do acordo
está sendo produzido. O acordo de contribuição individual do Google
foi uma das inspirações de como o novo sistema deve funcionar. O assunto já foi discutido
extensivamente, e muitas pessoas estão interessadas em uma solução. Além disso, estudos com relação
a validade do acordo em jurisdições fora dos EUA estão sendo feitos, certificando-se que o formato
eletrônico não afete o que esteja em vigor.
Google Summer of Code
Martin von Löwis apresentou detalhes de mais um ano do Google Summer of Code sob supervisão
da PSF. Incentiva-se desenvolvedores não só atuar como orientadores, mas também propor projetos
que possam ser realizados pelos estudantes - não se esqueça que ao propor um projeto, você não será
necessariamente o orientador. Se você estiver interessado em colaborar, acesse a página
Call for Projects and Mentors.
Distutils
O tópico Distutils2 apareceu em seguida, e Tarek Ziadé explicou que o objetivo
principal do sprint de programação foi o término da atualização para Python 3, e
a preparação para uma eventual fusão com a biblioteca padrão de Python. Além disso, a partir
da fusão, um novo nome: packaging. O grupo de desenvolvimento do packging também espera
disponibilizar um módulo independente, ainda chamado de Distutils2, com suporte para
Python 2.4 até 3.2.
O resultado do sprint de programação do packaging, o qual contou com um dos maiores grupos
de sprint na última PyCon, foi um grande sucesso. O pacote final está disponível no
Bitbucket, aguardando fusão com a biblioteca padrão.
O Futuro das VMs Alternativas
O grupo do IronPython anunciou seus planos futuros, sendo que o lançamento de uma
versão 3.x é o próximo objetivo. Também anunciaram a nova versão 2.7.0 na última PyCon,
o primeiro lançamento baseado em esforços da comunidade de programadores, desde que
o projeto foi entregue pela Microsoft; o desenvolvimento da versão se iniciará nos
próximos meses.
Jython recentemente lançou a versão 2.5.2, com planos para a versão 2.6 já sendo preparados.
Alguns desenvolvedores sugeriram passar diretamente para a versão 2.7, devido à pouca diferença
com relação a 2.6, mas isso poder acarretar um pouco de atraso. "Release early, release often" foi
uma das sugestões das conversas, o que pode fazer Jython ir diretamente da versão 2.6 para 3.x, além de considerar
diferenças entre 2.6 e 2.7.
Fomento para programação
Nas conversas de planejamento da versão 3.x, um do tópicos discutidos foi o de
financiamento para trabalhos de desenvolvimento, e como viabilizar a implementação de
versões alternativas com agilidade. Mesmo com dinheiro disponível, propostas devem ser encaminhadas
à PSF antes de iniciar qualquer atividade. Aqueles interessados em solicitar fundos
por esses tipos de trabalhos, favor entrar em contato com o grupo de administração da PSF.
Python "Baseline" (básico)
Jim Fulton trouxe ao grupo a discussão de uma versão de Python, por ele chamada
de "baseline". Sua experiência na implantação de aplicativos Python em diversos
sistemas, Jim mencionou o fato de que el alguns casos a versão Python de sistema
instalada e disponível, geralmente é imprevisível. Contando com a presença de
especialistas nas distribuições Linux Ubuntu/Debian e Fedora, foi possível analisar
como tudo está configurado no momento.
Na Fedora, o Python de sistema instalado tem como base o Live CD da distribuição, o que leva
a uma instalação mínima e com poucas dependências, o mínimo necessário para se ter
um sistema funcional. Outras discrepâncias podem ser vistas na forma que diretórios são
criados, remoção de módulos da biblioteca padrão, Distutils por exemplo, ou módulos
datados.
Aparentemente, ainda não há um consenso ou solução, mas os grupos envolvidos continuarão
a trabalhar na questão.
Recursos 3.3
Algumas sugestões foram dadas com relação a versão 3.4, incluindo duas PEPs.
PEP 382, que cobre "Namespace
Packages", deve aparecer logo no ciclo de desenvolvimento. Tal PEP foi também
mencionada na discussão da fusão do Distutils.
PEP 393, a qual define uma implementação
de string flexível, também foi discutida, com estudantes envolvidos no projeto GSoC
se interessando. Juntamente com a implementação, características como performance e
utilização de memória deverão ser analisadas mais a fundo, visando a implementação ou
não da proposta.
Unladen Swallow
Unladen Swallow no momento está numa situação de "repouso" e não deve ser incluído
no CPython da maneira como está implementado. Visando avançar o seu desenvolvimento,
novos responsáveis pelo projeto deverão ser designados, já que os especialistas
não estão disponíveis no momento. Durante a discussão, foi novamente mencionado
que se a questão de desenvolvimento do Unladen Swallow se refere a financiamento,
propostas devem ser encaminhadas à PSF.
Enquanto a Unladen Swallow está em repouso e tem um futuro incerto, há de destacar
as contribuições do projeto para a comunidades Python e de código livre. Por exemplo, o módulo
de avaliação de performance usado pela Unladen Swallow é muito útil para se
testar implementações alternativas. Além disso, contribuições dos desenvolvedores da
Unladen Swallow para o LLVM e Clang ajudaram muito esses projetos.
Duas outras ideias de performance também foram brevemente discutidas, entre as quais
a proposta de Dave Malcoml para funções em-linha. Martin von Löwis mencionou um
módulo de extensão do JIT no qual está trabalhando, mesmo com ceticismo de alguns
desenvolvedores Python em relação à eficiência do JIT neste caso.
Criando um caminho para frameworks assíncronas
Finalizando a pauta do dia, foi discutida a integração do Twisted na biblioteca
padrão. A ideia principal é de uma alternativa ao asyncore, o que permitirá uma
transição mais fácil do Twisted ou de outras frameworks assíncronas.
O processo será detalhado em uma PEP, na qual foi sugerido, deve conter
também uma proposta similar para a referência do WSGI, mas direcionado a loops
assíncronos. Juntamente os autores da PEP, desenvolvedores do Twisted e outros
interessados deverão trabalhar em conjunto para definir se todos estão no mesmo
estágio do projeto e desenvolvimento.