terça-feira, 31 de maio de 2011

Conheça a Equipe: Brian Curtin

Esta postagem é parte da série "Conheça a Equipe", a qual tem a intenção de apresentar a equipe de desenvolvimento Python.

Nome:Brian Curtin
Localização:Chicago, IL
Página:http://blog.briancurtin.com/

Há quanto tempo você usa Python?

Diariamente, comecei há cerca de seis anos. Antes disso usava de vez em quando em matérias na faculdade e em estágios no verão.

Há quanto tempo você tem desenvolvido para a linguagem?

Há pouco mais de um ano. No dia 24 de Março completo um ano com o grupo.

Como você começou como desenvolvedor do núcleo de Python? Você se lembra da sua primeira contribuição?*

Comecei quando percebi um "bug" na documentação enquanto escrevia um módulo de extensão no trabalho, enviei um "patch" que foi inserido quase que imediatamente pelo Georg Brandl. Depois do meu sucesso inicial e um novo "checkout" do código fonte, eu quis me aprofundar e aprender mais sobre os módulos que eu usava e acabei escrevendo um "patch" para adicionar suporte de "context manager" no zipfile.

Minhas primeiras contribuições foram para acertos na documentação tentando simplificá-la. A primeira contribuição de código foi para adicionar novos recursos e melhorar a cobertura de testes no módulo winreg.

Em quais partes de Python você está trabalhando no momento?

Como um dos poucos usuários de Windows envolvidos no desenvolvimento de CPython, eu tento me concentrar nos problemas que usuários de Windows estejam tendo com Python. Por causa disso, eu tive a oportunidade de trabalhar em várias coisas da biblioteca padrão, incluindo módulos que eu nunca usei. Não fiz muita coisa com o interpretador propriamente dito, mas espero mudar.

Você utiliza Python para que quando não está trabalhando no núcleo da linguagem?

Eu crio uma variedade de ferramentas de teste para um banco de dados financeiro, o qual é programado em C++. Um módulo de extensão existe para a API, o que facilita o desenvolvimento de testes de regressão, performance; estamos sempre tentando incluir novas ferramentas.

O que você gosta de fazer quando não está programando?

Eu sou grande admirador de basebol. Eu oficio basebol entre faculdades durante a primavera, outras ligas durante o verão, e aproveito para assistir os jogos do Chicago Cubs.

Conheça a Equipe: Nick Coghlan

Esta postagem é parte da série "Conheça a Equipe", a qual tem a intenção de apresentar a equipe de desenvolvimento Python.

Nome:Nick Coghlan
Localização:Brisbane, Australia
Página:http://www.boredomandlaziness.org

Há quanto tempo você usa Python?

Primeiro contato foi com 1.5.2 por volta de 1999 quando nosso instrutor utilizou num curso de redes. Comecei a usar a versão 2.2 profissionalmente para testes automatizados por volta de 2002 e nunca mais deixei.

Há quanto tempo você tem desenvolvido para a linguagem?

Guido me deu acesso em 2005 para atualizar a PEP 343 (para remover o "context method")

Como você começou como desenvolvedor do núcleo de Python? Você se lembra da sua primeira contribuição?*

Com relação a contribuir "patches", eu tirei 3 meses de férias em 2004 e acabei trabalhando com Raymond e Facundo no módulo decimal, rodando as "benchmarks" de telco e procurando meios de fazer o código ficar mais rápido. Um dos "hacks" mais estranhos foi no módulo de decimais (como o caminho mais rápido para checar se casos especiais e o uso de "strings" na conversão de "tuples" de dígitos para inteiros) vem daquela época.

Na verdade, minha primeira contribuição foi para a PEP 343, e provavelmente depois para o ramo do compilador AST, quando terminamos para inclusão no Python 2.5.

Em quais partes de Python você está trabalhando no momento?

runpy, functools e contextlib são as partes principais que acabam por aparecer na minha caixa de entrada. Eu também dou uma olhada no que Brett e Victor estão fazendo com import, o que Raymond está fazendo com collections e itertools, e qualquer coisa que esteja acontecendo no compilador. Eu também sou fascinado pelo ângulo cultural de tudo.

Você utiliza Python para que quando não está trabalhando no núcleo da linguagem?

Nada de mais, na verdade. Coisas de Python no trabalho praticamente se fazem sozinhas, e no final não há muita necessidade de se criar "hacks" no momento. O que eu quero realmente fazer é algo que organize minha coleção de música digital, mas os scripts pra isso são bem primitivos no momento.

O que você gosta de fazer quando não está programando?

Tae kwon do, vídeo games, futebol, leitura, etc, etc...

segunda-feira, 30 de maio de 2011

Novo Design para o Blog

Se você lê o Python Insider através de um leito de "feeds", talvez você não tenha visto o novo design que Marcin Wojtczuk criou para a nossa página. Parece bem bonito, além de ter um ar de página leve para carregar. Não poderíamos estar mais contentes com o resultado.

Obrigado pelo tempo e esforço, Marcin!

Correção da vulnerabilidade de segurança do urllib/urllib2

Guido van Rossum publicou recentemente uma correção para CVE-2011-1521, um problema de segurança nas bibliotecas URL de Python. Embora problemas de segurança sejam raros, a oportunidade é boa para abrir o processo para a comunidade, no que tange a relatar, direcionar e corrigir problemas quando eles aparecem.

Relatar um problema

Se você encontrar um problema de segurança em CPython, o que pedimos inicialmente é que você mantenha detalhes do problema em segredo. Depois de determinar que você encontrou um legítimo problema, é importante que um relatório, sucinto mas completo, dever ser feito ao desenvolvedores do núcleo, de maneira a demonstrar o que foi encontrado.

Um bom relatório deve explicar claramente as seções do código fonte afetadas pelo sistema. É importante se saber se o problema ocorrer em uma determinada plataforma ou é devido à uma dependência. Também, se conhecer as versões afetadas seria bem útil, mesmo que a vulnerabilidade seja testada na maioria das versões disponíveis. E se você tiver um teste que mostre o problema, por favor o inclua. Seu relatório deve ser enviado para o grupo security@python.org.

Niels Heinen, da Equipe de Segurança do Google, recentemente enviou um bom relatório. Ele descobriu um problema com o gerenciamento de redirecionamentos 302 do HTTP, nos módulos urllib e urllib2 da biblioteca padrão. Ele encontrou o problema no qual um servidor poderia redirecionar requisições para esquemas não apropriados, levando a situações que poderiam comprometer dados ou sistemas. No seu relatório inicial, Niels demonstrou duas situações nas quais tais redirecionamentos poderiam levar a problemas.

Primeiramente, já que urllib/urllib2 definem um gerenciamento para o esquema de URL file://, um redirecionamento para file:///etc/passwd poderia expor dados de senhas. Niels também explicou que redirecionamentos para um dispositivo do tipo file:///dev/zero poderia levar a um problema de "denial of service"

Recebimento de Relatórios

Dada a confidencialidade de relatórios de segurança, a lista security@python.org é mantida por um pequeno grupo de desenvolvedores confiáveis, que analisam e checam os relatórios assim que recebidos. Se você quiser enviar mensagens criptografadas para a lista, veja a página security news para detalhes a respeito do OpenPGP.

Se o grupo confirmar a existência de um problema de segurança, um bug público é criado com o "patch" necessário. Nesse caso, Guido van Rossum, publicou abertamente o problema #11662, completo com "patch" inicial.

Consertando o Problema

O "patch" de Guido restringiu os redirecionamentos de URL http://, https://, e ftp://. Redirecionamento de FTP foi considerado aceitável, o qual também é um redirecionamento bem comum: espelhos sistemas de download algumas vezes redirecionam requisições para servidores de FTP em regiões geográficas mais próximas do pedido.

Em Python 2.x, o método redirect_internal do FancyURLopener agora mostra um IOError quando o redirecionamento é inapropriado. Em HTTPRedirectHandler, http_error_302 faz a mesma coisa, só que apresentando HTTPError. Em Python 3, urllib.request recebeu as mesmas modificações. Incluídos no "patch" estão dois testes que testam redirecionamentos para esquemas válidos e inválidos.

Com relação a usuários receberem as modificações, o lançamento final de segurança do Python 2.5 será em breve. Como não há datas para os novos anúncios dos próximos "patches" de manutenção - 2.6, 2.7, 3.1 e 3.2 - todos receberam as modificações.

sexta-feira, 20 de maio de 2011

Conheça a Equipe: Tarek Ziadé

Esta postagem é parte da série "Conheça a Equipe", a qual tem a intenção de apresentar a equipe de desenvolvimento Python.

Há quanto tempo você usa Python?

Há cerca de 10 anos.

Há quanto tempo você tem desenvolvido para a linguagem?

Desde 21 de dezembro de 2008.

Como você começou como desenvolvedor do núcleo de Python? Você se lembra da sua primeira contribuição?*

Eu iniciei meu trabalho como desenvolvedor do núcleo para realizar a manutenção do Distutils e melhorá-lo.

Minha primeira contribuição foi um conserto de um "bug" em um dos recursos do distutils que eu propus antes de me tornar desenvolvedor do núcleo de Python. Aquele recurso foi adicionado uma semana antes em Python. É a possibilidade de configurar o registro do Distutils e enviar comandos que trabalhem com servidores semelhantes a pypi.

Eu contribuí com atribuições novas numa quarta-feira, 28 de dezembro de 2008, que também é meu aniversário, além de ser os 17o aniversário da versão 0.9.4 de Python.

Em quais partes de Python você está trabalhando no momento?

No stdlib: sysconfig, distutils, packaging (a ser incluído na versão 3.3), shutil, pkgutil, e de vez em quando em outros módulos.

Você utiliza Python para que quando não está trabalhando no núcleo da linguagem?

Eu trabalho para a Mozilla, na equipe de serviços, aonde faço serviços web com Python.

O que você gosta de fazer quando não está programando?

Eu leio revistas em quadrinhos, graphic novels, escrevo livros, brinco com meus filhos, bebo vinho com a minha esposa, e tento reformar no casa de 1848.

quinta-feira, 19 de maio de 2011

Formalização da Política de Controle de Mudanças na AST

Python expões uma árvore de sintaxe abstrata (AST, abstract syntax tree, no inglês), a qual representa a forma compilada do código fonte de Python no módulo AST. Este módulo permite ao usuário inspecionar e manipular a representação da AST, entre a análise do código e compilação do tipo bytecode.

Embora o significado do código Python é definido por uma referência de linguagem, o módulo AST é uma implementação em CPython, e implementações em outros tipos de Python não é necessária.

Compatibilidade do AST

Como parte do trabalho para reescrever o optimizador do vigia de CPython para funcionar no AST (ao invés do bytecode puro, como feito no momento), Eugene Toder precisou fazer alguma mudanças na estrutura do AST. Como a implementação de CPython não deixava claro qual o tipo de compatibilidade reversa precisavam ser usadas no AST. Eugene então perguntou na lista python-dev: "Seria necessário compatibilidade reversa para alterações no AST?".

O consenso geral foi de que tal compatibilidade não era necessária. O módulo AST expõe uma constante, ast.__version__, a qual permite ao código do usuário variar seu comportamento dependente da versão do AST que é encontrada. Isto foi tido como suficiente no que tange a compatibilidade, para uma implementação específica.

Outras implementações de Python

Na realidade, tanto mantedores de Jython quanto de IronPython comentaram que as suas respectivas implementações já têm um módulo AST compatível, ou pretendem implementar um. Mesmo assim, eles não acharam que isso significa que o AST deva ser "congelado", e ficariam satisfeitos com o fato da constate ast.__version__ mude, já que o AST poderia ser modificado de maneira incompatível.

Um ponto que foi levantado é que um pacote de testes complete em test_ast.py ajudaria outras implementações, fazendo que fosse certificado que as representações de AST sejam compatíveis com CPython. Aumentar a abrangência de test_ast.py seria um excelente projeto para alguém interessado em se envolver com Python.

E agora?

Um "patch", o qual iniciou a discussão, ainda não foi incluído em CPython. Possivelmente, nada deve acontecer. No entanto, no caso de ser adicionado, AST vai ser alterado de uma maneira compatível. A constante ast.__version__ deve mudar para refletir as alterações, o que fará com que códigos de usuários sejam avisados, mas outras mudanças devem ser necessárias. De maneira geral, mudanças no AST serão feitas dessa maneira no futuro.

Desenvolvedores Python estão interessados na amplitude do uso de AST, e qual será o impacto dessas determinações. Se leitores têm código que será afetado pela mudança, sua participação é incentivada na lista de discussões python-dev.

terça-feira, 17 de maio de 2011

Thomas Heller não é mais o mantenedor de ctypes

A comunidade de desenvolvimento de Python agradece em muito o longevo mantenedor de ctypes, Thomas Heller. Há algum tempo, Thomas anunciou que estava deixando o projeto CPython, o lar da sua biblioteca ctypes desde Python 2.5.

Tivemos uma oportunidade de conversar com Thomas, aonde ele nos contou sua história com Python e seus projetos ctypes e py2exe.

Python

Em 1999, Thomas buscava maneiras de aprender Python, encontrou Programming Python de Mark Lutz, e ficou fascinado com a linguagem. Naquele tempo ele também estava tentando substituir Scheme nas extensões de C para uma programa que ele desenvolvia no momento.

Com relação ao seu envolvimento com a equipe de desenvolvedores Python, sua primeira contribuição para CPython (e programas de código aberto), foi um pequeno "patch" em distutils para Windows. O seu interesse com distutils, o levou a criação do comando bdist_wininst que criava pacotes de instalação para Windows. A partir daquele ponto, Greg Ward o convidou para participar do grupo python-dev, quando foi permitido que ele enviasse contribuições.

py2exe

Como muitos usuários Windows, ele tinha a necessidade de instalar aplicativos Python em um só executável. Soluções anteriores para o problema haviam sido propostas por alguns eruditos em Python, como squeeze de Fredrik Lundh e sqfreeze de Christian Tismer, além de alguns "patches" que Thomas contribuiu para o projeto Installer de Gordon McMillan.

Seu interesse no distutils levou Thomas a considerar transformar Installer numa extensão da biblioteca de empacotamento. No entanto, ele acabou rescrevendo o código fonte para que pudesse usar as já existentes capacidades do distutils. No final, ele escolheu um nome simples mas bem descritivo para o projeto: py2exe.

ctypes

A ideia para ctypes veio de uma necessidade de se ir além daquilo que pywin32 permitia no momento. Seu trabalho com Scheme também necessitava de uma interface para APIs do Windows, da mesma maneira que Python, o que o fez manter o projeto ativo.

ctypes teve seu primeiro lançamento em 2003, por volta da mesma época que Python 2.3 foi lançado, depois de Thomas ter recebido inúmeros pedidos para publicar o projeto. Ele mencionou que este era seu pequeno projeto pessoal na sua página Starship, mas transformou-se em uma biblioteca largamente usada em pouco tempo.

Ele iniciou o projeto originalmente em Windows, mas rapidamente recebeu pedidos de uma versão Linux, a qual a comunidade o ajudou a terminar. Com a versão Linux, veio o desenvolvimento de libffi, a qual ele também passou a usar em Windows para substituir sua implementação de baixo-nível.

2006 foi marcado pela versão 1.0 de ctypes, a qual coincidiu com a inclusão do módulo na biblioteca padrão de Python 2.5. Após vários anos de trabalho duro e diversas versões por ano, ctypes finalmente havia sido incorporada a Python e disponível para uma audiência muito maior.

Muitas pessoas contribuíram para que ctypes seja o que é atualmente, e Thomas gostaria de agradecer a todos os envolvidos, especialmente Robin Becker. Robin foi imprescindível nas fases iniciais do projeto e contribui com conhecimento e incentivo.

Um novo mantenedor para ctypes

Após todo o esforço de Thomas durantes os últimos anos, seria muito mal deixar o projeto parar. Se você tem experiência em C e tempo para ajudar o projeto em Python, a comnunidade agradeceria enormemente. Dê uma olhada no novo guia de desenvolvimento e veja a list de bugs para maiores informações.

sexta-feira, 13 de maio de 2011

Conheça a Equipe: Benjamin Peterson

Esta postagem é parte da série "Conheça a Equipe", a qual tem a intenção de apresentar a equipe de desenvolvimento Python.

Nome:Benjamin Peterson
Lugar:Minnesota, USA
Home Page:http://benjamin-peterson.org
Blog:http://pybites.blogspot.com

Há quanto tempo você usa Python?

Três anos e meio

Há quanto tempo você tem desenvolvido para a linguagem?

Exatamente há três anos no dia 25 de Março.

Como você começou como desenvolvedor do núcleo de Python? Você se lembra da sua primeira contribuição?*

Minha primeira proposta foi rejeitada pelo próprio Guido. Felizmente, persisti e alguns "patches" que eu enviei foram aceitos. Imagino que a minha primeira contribuição tenha sido um reordenamento do arquivo Misc/ACKS.

Em quais partes de Python você está trabalhando no momento?

Eu gosto do núcleo de "parser", compilador e interpretação, mas eu fique conhecido por mexer na maioria das partes do núcleo da linguagem ... com exceção de Windows!

Você utiliza Python para que quando não está trabalhando no núcleo da linguagem?

Eu uso para implementar um interpretador de Python. Eu sou um implementador de Python coração :) . Eu fui o criador do six, uma biblioteca de compatibilidade entre as versões 2 e 3.

O que você gosta de fazer quando não está programando?

Compor, tocar clarineta, e ler livros de matemática. Às vezes, também faço trilhas.

quinta-feira, 12 de maio de 2011

Código obsoleto entre 2.7 e 3.2

Discussões recentes na lista python-dev trouxe à tona as determinações de obsolência de código entre os desenvolvedores trabalhando com as mudanças da versão 2.7 para 3.2. Graças a essa discussão, a equipe de desenvolvedores modificou as determinações de obsolência de código, levando em conta que usuários de Python migrarão diretamente da versão 2.7 para 3.x, sem passar por qualquer versão intermediária.

Perspectiva

A linguagem Python tem um grande compromisso com compatibilidade de versões anteriores. Nenhuma alteração é permitida sem antes obedecer orientações de compatibilidade, o que, essencialmente, diz que programas sem erros de código não devem se tornar incorretos com o uso de novas versões de Python. No entanto, isso nem sempre é possível, por exemplo quando a API tem problemas que devem ser modificados por novas versões. Nesse caso, Python segue uma política de obsolência baseada num período de transição anual, no qual recursos considerados obsoletos são formalmente removidos. No período entre transições, um aviso de obsolência é dado a todos os desenvolvedores, visando uma atualização de código. Informações sobre as determinações de obsolência estão documentadas na PEP 5. Como modificações só podem ser feitas em novos releases, e há um intervalo de 18 meses entre releases, isto quer dizer que é normal um período de obsolência de um release.

A única exceção as essas normas é Python 3. A mudança de versão de Python 2 para 3 foi especificamente planejada para englobar mudanças que possam não ser compatíveis com versões antigas, permitindo aos desenvolvedores de Python corrigir defeitos que não poderiam ser corrigidos com a atual normativa. Por exemplo, transformar strings em Unicode, e retornar iterators ao invés de listas.

Linhas de Desenvolvimento Paralelas

Sabendo-se que a transição para Python 3 demoraria algum tempo, algumas estimativas apontam 5 anos, ficou claro que haveria um bom número de desenvolvimento em paralelo das versões 2 e 3.

Como o release final de Python dois é a versão 2.7, foi acordado que o período de manutenção seria estendido por um bom tempo. No final, programadores que querem atualizar-se com uma versão nova de Python, terão de mudar diretamente para Python 3.

Mas, existem alguns problemas ...

Obsolências surpresa

Em uma discussão da python-dev, um participante apontou para o fato de que uma função específica da API C, PyCObject_AsVoidPtr, foi removida com um aviso prévio curto demais. Mas as determinações de obsolência deveriam evitar tais tipos de problemas! O que poderia ter acontecido?

A alteração fazia parte de uma mudança maior, da API antiga (PyCObject) para uma nova e melhor (PyCapsule). O problema é PyCObject é a padrão, e na realidade, a única API disponível em Python 2.6. Foi considerada obsoleta em Python 2.7. Em Python 3.2, essa API não existe, e a nova PyCapsule deve ser usada. Isso faz com que o período de obsolência desde o lançamento de Python 2.7 (Julho de 2010) até Python 3.2 (Fevereiro de 2011), cerca de sete meses. Bem aquém do tempo necessário de 12 meses, fazendo com que seja difícil para desenvolvedores mantenham um número razoável de versões.

Para alguém mudando de 3.0 para 3.1 e para 3.2, as obsolências não acarretam problemas. Python 3.1 foi lançado em Março de 2010, com a obsolência, e no ciclo 3.x, o tempo de 12 meses foi cumprido. No entanto, este não é o caminho escolhido por muitos: normalmente, desenvolvedores vão da versão 2.7 para o lançamento mais recente de 3.x, no caso 3.2, o que resulta em problemas. Esta nunca foi a ideia da python-dev, mas a PEP 5 não foi escrita para desenvolvimento de versões paralelas de Python, ambas sob desenvolvimento ativo.

O que fazer?

Mesmo que o caso PyCObject/PyCapsule da API seja mesmo um problema, não é impossível de contorná-lo. No entanto, pelo menos um desenvolvedor da python-dev teve dificuldades para lidar com o problema, e isto não pode acontecer.

No caso específico do PyCObject/PyCapsule, o problema já existe e não há muito o que se fazer. Reintroduzir PyCObject não era uma opção viável, o que acarretaria uma série de incompatibilidades. No entanto, o consenso geral era que seria possível, ainda que enfadonho, escrever código, adaptando a API atual. Na verdade, em Python 3.1, PyCObject foi escrito encapsulando a API PyCapsule. Foi sugerido que se alguém necessitasse da implementação, ela poderia ser extraída para uso de código externo. Além disso, foi acordado que uma PEP "retroativa" relatando a mudança deveria ser escrita, descrevendo as razões da mudança e documentar recursos que podem auxiliar desenvolvedores.

Em termos gerais, a equipe de desenvolvedores Python já está consciente do problema e vai trabalhar para evitar que isso ocorra novamente. Guido deu sua opinião sobre a situação e sugeriu que Python 3 deve ser conservador quanto a obsolências no momento. No mínimo, API obsoletas devem ser mantidas por um período maior, antes de serem removidas, permitindo que desenvolvedores possam migrar da versão 2.7 sem problemas.

Indiretamente, a discussão trouxe à tona o tópico de como comunicar alterações de maneira mais eficiente e oportuna para uma audiência maior, - uma das razões da existência deste blog.

Qual o significado disso tudo?

Em primeiro lugar, significa que os desenvolvedores de Python nem sempre acertam. Ninguém teve a intenção de tornar a vida dos programadores mais difícil; o que ocorreu foi uma falha que não foi detectada a tempo.

Além disso, consertar o problema pode acarretar mais problemas do que solucioná-los, fazendo com que a API PyCObject não seja reintegrada. A reintegração poderia ajudar desenvolvedores que foram pegos pelo problema, mas de maneira geral isso faria com que problemas de compatibilidade se tornassem mais complexos. Entretanto, temos de aceitar o problema e continuar trabalhando. Aprendemos a lição, e não cometeremos o mesmo erro da próxima vez.

Isso mostra que a equipe de desenvolvedores Python quer saber a opinião dos usuários. Compatibilidade é muito importante, e todos os esforços são feitos para tornar indolor a transição de versões. Em particular, desenvolvedores de bibliotecas devem ser capazes de manter múltiplas versões de Python com um nível de trabalho razoável.

E por fim, desenvolvedores ainda não abandonaram a versão 2.7. Mesmo que novos recursos não sejam adicionados a essa versão, e como não haverá versão 2.8, opiniões de pessoas ainda usando 2.7 é importante. Ter certeza de que usuários possam migrar para versões 3.x assim que se sentirem prontos para tal, é vital para toda a comunidade Python.

domingo, 8 de maio de 2011

Sobre polling, futuros e execução em paralelo

Uma das maiores preocupações na computação atual é economizar energia; algo bastante necessário em aparelhos portáteis (laptops, tablets, handhelds). Sua CPU é capaz de assumir diferentes tipos de estados de baixa-potência quando inativa. Quanto mais longo o período de inatividade, mais profundo o estado de baixa-potência, e maior a economia de energia, levando a uma carga de bateria mais durável.

Estados de baixa-potência têm um inimigo: "polling" (literalmente, votação). Quando uma tarefa ativa a CPU, mesmo que para algo trivial como leitura de endereços de memória para checar por mudanças que possam ter acontecido, a CPU deixa o estado de baixa-potência, ativa-se e ativa as estruturas internas, e só retornará a um estado de baixa-potência muito depois da simples leitura de memória ter finalizado o trabalho. Este tipo de atividade diminui muito a duração da carga da bateria. Até mesmo a Intel parece preocupada..

Python 3.2 apresenta um novo módulo padrão que inicia tarefas concomitantes e as espera terminar: o módulo concurrent.futures. Revendo o código presente neste módulo, percebemos que utiliza "polling" em alguns dos processos e "threads". Dizemos alguns, pois a implementação difere entre ThreadPoolExecutor e ProcessPoolExecutor. O primeiro produz "polling" entre todas as "threads" em funcionamento, enquanto o último só produz em uma "thread" apenas, conhecida como a "thread" de gerenciamento da fila de processo., a qual é utilizada para comunicar-se com a processos em funcionamento.

Aqui, "polling" foi usado para uma coisa só: detectar quando um processo de desligamento deve ser iniciado. Outras tarefas, tais como organizar procedimentos "callables" ou busca de resultados de tarefas prévias na fila, usam objetos sincronizados na fila. Estes objetos na fila veem tanto de "threading" ou de módulos de multiprocessamento, o que depende do que o implementação do executador estiver usando.

Desta maneira, apresentamos uma solução bem simples: substituímos o "polling" por uma sentinela (sentinel em inglês), chamado de "None". Quando uma fila recebe um "None", uma tarefa em processo é chamada, é checa se deve ser desligada ou não. No ProcessPoolExecutor, há uma pequena complicação, já que devemos reiniciar N tarefas, além da "thread" que gerencia a fila.

No "patch" inicial, ainda tínhamos um contador de "polling"; um contador bem longo (10 minutos), esperando que as tarefas se reiniciassem nesse período. Este contador era longo para casos de código com erros que não recebessem a tempo uma notificação de desligamento do sentinela mencionado acima. Por curiosidade, checamos o código fonte do módulo de multiprocessamento e tivemos uma outra observação bem interessante: em Windows, multiprocessing.Queue.get() com um contador diferente de zero e não infinito usa ... "polling" (por o qual, abrimos o problema 11668). Ele usa um "polling" de alta-frequência muito interessante, já que se inicia com um contador de um milissegundo, o qual é incrementado a cada iteração loop.

Desnecessário comentar que se utilizar um contador, não importando o quão longo, faria com que nosso patch fosse inútil no Windows, visto que a maneira que o contador foi implementado envolveria chamadas a casa milissegundo. Fizemos um sacrifício e removemos o enorme contador do "pooling". Nosso último patch não usa um contador, o que deve limitar o número de chamadas periódicas em qualquer plataforma.

Historicamente, antes do Python 3.2, cada contador no módulo de threading usa "polling", e por consequência em grande parte do multiprocessamento, o qual usa tarefas de processamento, usa "polling". Isto foi corrigido no número 7316.

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,

segunda-feira, 2 de maio de 2011

Bem-vindo ao Python Insider!

Python Insider é a tradução do blog oficial da equipe de desenvolvimento do Python core. Este blog é um resumo dos assuntos discutidos na lista de e-mail Python-Dev, com ênfase nas futuras mudanças na linguagem. Tentaremos fazer um resumo da atividade diária da lista, tais como as últimas PEPs (Python Enhancement Proposals) aprovadas, mudanças na API central e mais notícias relevantes da comunidade.

Este blog tem como princípio funcionar como um complemento à lista Python-Dev e aos blogs dos desenvolvedores Python (veja a lista na barra lateral desta página), e tentará servir como um canal de comunicação para que eventos importantes ligados ao desenvolvimento central da linguagem possam atingir um maio número de pessoas. Todos os comentários são bem-vindos, mas também esperamos que os interessados se registrem na lista de e-mail. para seguir as discussões com mais detalhes e talvez até se interessem por ajudar no desenvolvimento de Python.

A língua comum das discussões, além de Python, é o inglês. Desta maneira a melhor maneira de ter sua opinião ouvida pela comunidade é através dos canais originais, a lista Python-Dev e a versão em inglês desta página.

Como participar

Existem várias maneiras de seguir Python Insider:

Procura-se ajuda

Mesmo com uma equipe dedicada a escrever postagens nos diferentes blogs oficiais da linguagem, procuramos interessados com experiência em design gráfico para melhorar a aparência das páginas do Blogger.Também procuramos interessados em traduzir o blog para outros idiomas.

Para maiores informações, entre em contato com Doug Hellmann (doug dot hellmann no gmail).