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.
sexta-feira, 3 de junho de 2011
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.
quinta-feira, 2 de junho de 2011
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
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.
quarta-feira, 1 de junho de 2011
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).
Assinar:
Postagens (Atom)