sexta-feira, 6 de maio de 2011

Atualizações do Language Summit 2011

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.

Mais informações

Para maiores informações, acesse a notas http://www.boredomandlaziness.org/2011/03/python-language-summit-rough-notes.html e destaques http://www.boredomandlaziness.org/2011/03/python-language-summit-highlights.html de Nick Coghlan, desenvolvedor do CPython,

Nenhum comentário:

Postar um comentário