Traduções para Português, Alemão, Coreano e Chinês Tradicional

O translation project do Python Insider está aumentando! Estamos lançando traduções de Português, Alemão, Coreano e Chinês Tradicional. Os tradutores já começaram a publicar as postagens do original em inglês. Estas traduções em paralelo podem ficar um pouco atrasadas das postagens do Python Insider.

Novo módulo de detecção de falhas (faulthandler) do Python 3.3 ajuda no debugging

Quando um usuário relata que seu programa "dá pau", congela, às vezes você só pode tentar ajudar, obter maiores informações e tentar reproduzir o problema. Mesmo com informações detalhadas do usuário, programadores normalmente não são capazes de reproduzir o problema devido à diferenças de sistemas, tais como sistema operacional e compilador. Com sorte, o usuário pode instalar algumas ferramentas de debugging, mas na maioria das vezes você tem de esperar outras pessoas encontrarem o mesmo problema e dar maiores informações.

Erros Fatais

Um novo módulo, introduzido em Python 3.3, deve ajudar em situações semelhantes: faulthandler. faulthandler permite que um "traceback" seja salvo quando um erro fatal (fatal error) ocorrer, tais como "segmentation fault", divisão por zero, mensagens abortadas ou erro no "bus". Você pode ativá-lo dentro de um aplicativo usando o faulthandler.enable(), ou colocando a opção -X faulthandler no executável do Python, ou com a variável de sistema PYTHONFAULTHANDLER=1. Exemplo:

Fatal Python error: Segmentation fault

Current thread 0x00007f7babc6b700:
 File "Lib/test/crashers/gc_inspection.py", line 29 in g
 File "Lib/test/crashers/gc_inspection.py", line 32 in <module>
Segmentation fault

Timeout

faulthandler pode também salvar um "traceback" após algum tempo com faulthandler.dump_tracebacks_later(timeout). Ative-o novamente para reiniciar a contagem ou use faulthandler.cancel_dump_tracebacks_later() para parar a contagem. Exemplo:

Timeout (0:01:00)!
Current thread 0x00007f987d459700:
 File "Lib/test/crashers/infinite_loop_re.py", line 20 in <module>

Use a opção repeat=True para salvar um "tracebakc" a cada n segundos de timeout, ou exit=True para sair do programa imediatamente, de forma não segura, e.g. sem arquivos de saída.

Sinal do Usuário

Se você tem acesso ao computador que esteja rodando o programa, você ainda pode usar o faulthandler.register(signal) para instalar o gerente de sinais que salva o "traceback" quando o sinal é recebido. Em UNIX, por exemplo, você pode usar o sinal SIGUSR1: kill -USR1 <pid> salva o "traceback" atual. Este recurso não está disponível em Windows. Exemplo:

Current thread 0x00007fdc3da74700:
 File "Lib/test/crashers/infinite_loop_re.py", line 19 in <module>

Outra possibilidade é ativa explicitamente faulthandler.dump_traceback() no seu programa.

Problemas de segurança e o arquivo de saída

faulthandler é desativado por padrão, por razões de segurança, sobretudo porque ele arquiva a descrição do arquivo sys.stderr e salva os "tracebacks" no seu arquivo de descrição. Se o sys.stderr é fechado e o arquivo de descrição é reutilizado, o arquivo de descrição pode ser um "socket", um "pipe" ou arquivo crítico ou algo mais. Por padrão, faulthandler escreve "tracebacks" em sys.stderr, mas outro arquivo pode ser especificado. Para maiores informações, leia a documentação do faulthandler.

Módulos terceirizados para versões antigas de Python

faulthandler também mantido como um módulo terceirizado para Python 2.5 até 3.2 em PyPI. A maior diferença entre o Python 3.3 e o módulo terceirizado é a implementação do dump_tracebacks_later(): Python 3.3 usa uma "thread" com um alarme de tempo em um "lock", enquanto o módulo terceirizado usa SIGALRM e alarm().

O alarme de tempo do "lock" é uma novo recurso de Python 3.3, tem uma resolução de microssegundos. O contador de alarm() usado é usado em versões mais antigas, e o sinal do SIGALRM pode interromper a chamada de sistema atual, a qual falhará com um erro EINTR.

Sucesso Inicial

O novo módulo faulthandler já ajudou a localizar "race conditions" nos "buildbots". Esperamos que possam ajudar vocês com seus programas.

Traduções para Romeno e Chinês Simplificado

A equipe do Python Insider está bem feliz em anunciar mais dois blogs. Tradutores de Romeno e Chinês Simplificado se juntaram ao Translation Project, e já começaram a publicar as postagens da versão em Inglês. Como as outras traduções, estas edições paralelas podem ficar um pouco defasadas da versão original.

Jython migrou para Mercurial

Jython finalmente migrou de Subversion para Mercurial. Foi ums longa jornada: infelizmente, tivemos um repositório Subversion que foi um pouco trabalhoso para converter de maneira eficiente para o novo sistema de revisões.

O novo repositório Jython está localizado em

http://hg.python.org/jython

com um espelho no BitBucket for facilitar a bifurcação.

Há também um repositório "read-only" com ramos de recursos (convertidos com bookmarks Mercurial) em http://hg.python.org/jython-fullhistory

Mercurial também torna mais fácil contribuir para Jython, bifurque e nos ajude a criar Jython 2.6!

Python 3.3 vai deixar de suportar OS/2, Windows 2000 e VMS

De vez em quando chega o momento de eliminar alguns sistemas operacionais da lista de sistemas compatíveis para se ajustar à aquilo que os usuários têm usado. Também o número de desenvolvedores que contribuem para cada plataforma é significativo, já que é sempre necessário ter alguém a postos para que os novos lançamentos sejam na data correta e de qualidade. Outros fatores, tais como a idade do sistema operacional e os entraves para desenvolvimentos futuros também pesam na lista.

Victor Stinner recentemente propôs abandonar o suporte a OS/2 e VMS para CPython, um ano após a sua pergunta inicial sobre o suporte a OS/2. A questão inicial de Victor surgiu no momento em que ele trabalhava sem para em Unicode, mais especificamente em problemas com os.execvpe() e variáveis de sistema pela PEP 383 do surrogateescape. OS/2 e VMS no momento não estão representados no time de desenvolvedores e não são testados durante o processo de novos lançamentos da linguagem.

Ao escrever esta postagem, comecei a pensar sobre uma discussão anterior sobre deixar Windows 2000, o qual parecia cair no esquecimento. Sistemas com COMSPEC a command.com também estavam em processo de perda de suporte. A partir de agora ambos se juntam ao OS/2 e VMS. Windows 2000 também deixará de ter suporte, para que o trabalho de desenvolvimento seja mais simples, fazendo com que APIs antigas não sejam mais um problema, num sistema operacional que terminou seu ciclo em 2010.

De maneira a começar a deixar de suportar estes sistemas, estamos modificando a PEP 11.

PEP 11

Esta PEP delineia os sistemas operacionais que não são mais suportados e explica qual o processe de se adicionar um SO à lista.

Uma vez que se é decidido que um sistema deve ser removido, um anúncio formal da remoção é feito. Este anúncio é tradicionalmente feito para a versão que está em desenvolvimento, ou seja deixar o suporte para OS/2, VMS e Windows 2000 será feito para a versão Python 3.3.

O estágio inicial é feito automaticamente, como se levantar uma bandeira branca. O primeiro sinal é a falta de alguém disponível para manter o código e assegurar um lançamento de qualidade. Mudanças na compilação e instalação podem ser feitos para alertar usuários que a plataforma não é mais compatível. Uma nota então é colocada no documento "What's New" com a lista dos sistemas não mais suportados.

Após um ciclo de lançamentos sem suporte, a versão seguinte está pronta para remoção de código. Neste caso, código deve ser removido na versão 3.4. Provavelmente, não haverá uma remoção completa do código obsoleto, mas desenvolvedores que casualmente encontrem blocos #ifdef e seções configure obsoletos no código.

O que você pode fazer

Se você é usuário de OS/2 ou VMS, algumas coisas podem ser feitas para salvar sua plataforma.

Torne-se mantenedor

Nada é melhor para suporte do que um desenvolvedor ativo. Andrew MacIntyre tem sido o mantenedor de OS/2 já há algum tempo, e ele mencionou quando da pergunta inicial de Victor sobre OS/2, que o sistema está defasado quanto ai suporte de Unicode, e que essa deve ser uma área a ser trabalhada. Com relação a VMS, certo suporte existe pelo http://www.vmspython.org, mas com tem sido discutido no problema 11918, alguém tem de aparecer para manter o suporte a VMS.

Se você estiver interessado em assumir o desenvolvimento em uma das plataformas, dê uma olhada no developer's guide e veja o processo de desenvolvimento atual.

Contribua com um "build slave"

Com a presença de um mantenedor, plataformas têm uma maior chance de serem mantidas. Com um "build slave", as chances aumentam ainda mais, não só em ser mantida, mas também em qualidade.

Python usa o Buildbot para uma integração contínua, e "build slaves" são fornecidos para Linux, Mas, Windows e Open Indiana (Solaris), para várias versões, arquiteturas e configurações. Se você puder doar uma máquina ou tempo para manter OS/2 e VMS na lista de sistemas suportados, contate a lista python-dev.

Projeto de Tradução do Python Insider

Nós acreditamos que o conteúdo deste blog é muito útil à toda comunidade Python, e uma das nossas prioridades é atender o maior número de pessoas possíveis. De maneira a aumentar nosso alcance, organizamos um grupo de tradutores para criar versões em paralelo do blog em outras linguagens. Inicialmente, duas traduções foram incluídas: Japonês e Espanhol.

As traduções estarão um pouco atrasadas no começo em relação ao Python Insider, mas tentaremos atualizá-las.

Precisa-se de ajuda

As equipes de tradução ainda são pequenas, o que nos faz buscar pessoas que queiram se envolver. Precisamos de pessoas que possam ajudar nas traduções em qualquer língua. Interessados, favor contatar Doug Hellmann (doug dot hellmann at gmail).

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...

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.

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.

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.

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.

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.

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.

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.

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,

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:

• Planet Python
• Na rede
• Feed Atom/RSS
• @PythonInsider no Twitter (en inglês)
• Correio eletrônico

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).