tag:blogger.com,1999:blog-7284659817414575302023-11-15T09:53:03.242-05:00Python Insider PTPython core development news and information.Doug Hellmannhttp://www.blogger.com/profile/01892352754222143463noreply@blogger.comBlogger18125tag:blogger.com,1999:blog-728465981741457530.post-3427148221952096022011-06-03T13:47:00.002-04:002011-06-03T13:50:41.558-04:00Traduções para Português, Alemão, Coreano e Chinês Tradicional<div class="document" id="traducoes-para-portugues-alemao-coreano-e-chines-tradicional">
<p>O <a class="reference external" href="http://blog.python.org/2011/05/python-insider-translation-project.html">translation project</a> do Python Insider está aumentando! Estamos
lançando traduções de <a class="reference external" href="http://blog-pt.python.org/">Português</a>, <a class="reference external" href="http://blog-de.python.org/">Alemão</a>, <a class="reference external" href="http://blog-ko.python.org/">Coreano</a> e <a class="reference external" href="http://blog-tw.python.org/">Chinês Tradicional</a>.
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 <a class="reference external" href="http://blog.python.org/">Python Insider</a>.</p>
</div>Anonymoushttp://www.blogger.com/profile/12361293458447621754noreply@blogger.com0tag:blogger.com,1999:blog-728465981741457530.post-90814014316528766262011-06-03T13:33:00.002-04:002011-06-03T13:34:16.111-04:00Novo módulo de detecção de falhas (faulthandler) do Python 3.3 ajuda no debugging<div class="document" id="novo-modulo-de-deteccao-de-falhas-faulthandler-do-python-3-3-ajuda-no-debugging">
<p>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.</p>
<div class="section" id="erros-fatais">
<h4>Erros Fatais</h4>
<p>Um novo módulo, introduzido em Python 3.3, deve ajudar em situações semelhantes:
<a class="reference external" href="http://docs.python.org/dev/library/faulthandler.html">faulthandler</a>. <tt class="docutils literal">faulthandler</tt> 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 <tt class="docutils literal">faulthandler.enable()</tt>, ou colocando a opção <tt class="docutils literal"><span class="pre">-X</span> faulthandler</tt> no
executável do Python, ou com a variável de sistema <a class="reference external" href="http://docs.python.org/dev/using/cmdline.html#envvar-PYTHONFAULTHANDLER">PYTHONFAULTHANDLER=1</a>. Exemplo:</p>
<pre class="literal-block">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
</pre>
</div>
<div class="section" id="timeout">
<h4>Timeout</h4>
<p><tt class="docutils literal">faulthandler</tt> pode também salvar um "traceback" após algum tempo com
<tt class="docutils literal">faulthandler.dump_tracebacks_later(timeout)</tt>. Ative-o novamente para reiniciar
a contagem ou use <tt class="docutils literal">faulthandler.cancel_dump_tracebacks_later()</tt> para parar a contagem.
Exemplo:</p>
<pre class="literal-block">Timeout (0:01:00)!
Current thread 0x00007f987d459700:
File "Lib/test/crashers/infinite_loop_re.py", line 20 in <module>
</pre>
<p>Use a opção <tt class="docutils literal">repeat=True</tt> para salvar um "tracebakc" a cada n segundos de <tt class="docutils literal">timeout</tt>,
ou <tt class="docutils literal">exit=True</tt> para sair do programa imediatamente, de forma não segura, e.g. sem
arquivos de saída.</p>
</div>
<div class="section" id="sinal-do-usuario">
<h4>Sinal do Usuário</h4>
<p>Se você tem acesso ao computador que esteja rodando o programa, você ainda pode usar o
<tt class="docutils literal">faulthandler.register(signal)</tt> para instalar o gerente de sinais que salva o "traceback"
quando o <tt class="docutils literal">sinal</tt> é recebido. Em UNIX, por exemplo, você pode usar o sinal <tt class="docutils literal">SIGUSR1</tt>:
<tt class="docutils literal">kill <span class="pre">-USR1</span> <pid></tt> salva o "traceback" atual. Este recurso não está disponível em
Windows. Exemplo:</p>
<pre class="literal-block">Current thread 0x00007fdc3da74700:
File "Lib/test/crashers/infinite_loop_re.py", line 19 in <module>
</pre>
<p>Outra possibilidade é ativa explicitamente <tt class="docutils literal">faulthandler.dump_traceback()</tt> no seu
programa.</p>
</div>
<div class="section" id="problemas-de-seguranca-e-o-arquivo-de-saida">
<h4>Problemas de segurança e o arquivo de saída</h4>
<p><tt class="docutils literal">faulthandler</tt> é desativado por padrão, por razões de segurança, sobretudo porque ele
arquiva a descrição do arquivo <tt class="docutils literal">sys.stderr</tt> e salva os "tracebacks" no seu arquivo de descrição.
Se o <tt class="docutils literal">sys.stderr</tt> é 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, <tt class="docutils literal">faulthandler</tt>
escreve "tracebacks" em <tt class="docutils literal">sys.stderr</tt>, mas outro arquivo pode ser especificado. Para
maiores informações, leia a <a class="reference external" href="http://docs.python.org/dev/library/faulthandler.html#file-descriptor-issue">documentação do faulthandler</a>.</p>
</div>
<div class="section" id="modulos-terceirizados-para-versoes-antigas-de-python">
<h4>Módulos terceirizados para versões antigas de Python</h4>
<p><tt class="docutils literal">faulthandler</tt> também mantido como um módulo terceirizado para Python 2.5 até
3.2 em <a class="reference external" href="http://pypi.python.org/pypi/faulthandler/">PyPI</a>. A maior diferença entre o Python 3.3 e o módulo terceirizado é a
implementação do <tt class="docutils literal">dump_tracebacks_later()</tt>: Python 3.3 usa uma "thread" com um alarme
de tempo em um "lock", enquanto o módulo terceirizado usa <tt class="docutils literal">SIGALRM</tt> e <tt class="docutils literal">alarm()</tt>.</p>
<p>O alarme de tempo do "lock" é uma novo recurso de Python 3.3, tem uma resolução
de microssegundos. O contador de <tt class="docutils literal">alarm()</tt> usado é usado em versões mais antigas,
e o sinal do <tt class="docutils literal">SIGALRM</tt> pode interromper a chamada de sistema atual, a qual falhará
com um erro <tt class="docutils literal">EINTR</tt>.</p>
</div>
<div class="section" id="sucesso-inicial">
<h4>Sucesso Inicial</h4>
<p>O novo módulo <tt class="docutils literal">faulthandler</tt> já ajudou a localizar "race conditions" nos
"buildbots". Esperamos que possam ajudar vocês com seus programas.</p>
</div>
</div>Anonymoushttp://www.blogger.com/profile/12361293458447621754noreply@blogger.com0tag:blogger.com,1999:blog-728465981741457530.post-72316944026456249412011-06-03T09:50:00.002-04:002011-06-03T09:52:14.378-04:00Traduções para Romeno e Chinês Simplificado<div class="document" id="traducoes-para-romeno-e-chines-simplificado">
<p>A equipe do <a class="reference external" href="http://blog.python.org/">Python Insider</a> está bem feliz em anunciar mais dois blogs.
Tradutores de <a class="reference external" href="http://blog-ro.python.org/">Romeno</a> e <a class="reference external" href="http://blog-cn.python.org/">Chinês Simplificado</a> se juntaram ao
<a class="reference external" href="http://blog.python.org/2011/05/python-insider-translation-project.html">Translation Project</a>, 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.</p>
</div>Anonymoushttp://www.blogger.com/profile/12361293458447621754noreply@blogger.com0tag:blogger.com,1999:blog-728465981741457530.post-90561279287085487112011-06-02T14:15:00.002-04:002011-06-02T14:15:50.853-04:00Jython migrou para Mercurial<div class="document" id="jython-migrou-para-mercurial">
<p>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.</p>
<p>O novo repositório Jython está localizado em</p>
<p><a class="reference external" href="http://hg.python.org/jython">http://hg.python.org/jython</a></p>
<p>com um <a class="reference external" href="http://bitbucket.org/jython/jython">espelho no BitBucket</a> for facilitar a bifurcação.</p>
<p>Há também um repositório "read-only" com ramos de recursos (convertidos
com bookmarks Mercurial) em <a class="reference external" href="http://hg.python.org/jython-fullhistory">http://hg.python.org/jython-fullhistory</a></p>
<p>Mercurial também torna mais fácil contribuir para Jython, bifurque e nos ajude
a criar Jython 2.6!</p>
</div>Anonymoushttp://www.blogger.com/profile/12361293458447621754noreply@blogger.com0tag:blogger.com,1999:blog-728465981741457530.post-55907619239024966962011-06-02T13:18:00.003-04:002011-06-02T13:23:30.506-04:00Python 3.3 vai deixar de suportar OS/2, Windows 2000 e VMS<div class="document" id="python-3-3-vai-deixar-de-suportar-os-2-windows-2000-e-vms">
<p>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.</p>
<p><a class="reference external" href="http://www.haypocalc.com/wiki/Victor_Stinner">Victor Stinner</a> recentemente propôs <a class="reference external" href="http://mail.python.org/pipermail/python-dev/2011-April/110872.html">abandonar o suporte a OS/2 e VMS</a> para CPython,
um ano após a sua <a class="reference external" href="http://mail.python.org/pipermail/python-dev/2010-April/099471.html">pergunta inicial</a> 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 <a class="reference external" href="http://docs.python.org/library/os#os.execvpe">os.execvpe()</a> e variáveis de sistema pela <a class="reference external" href="http://www.python.org/dev/peps/pep-0383/">PEP 383</a> 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.</p>
<p>Ao escrever esta postagem, <a class="reference external" href="http://mail.python.org/pipermail/python-dev/2011-May/111159.html">comecei a pensar</a> sobre uma <a class="reference external" href="http://mail.python.org/pipermail/python-dev/2010-March/098074.html">discussão anterior</a>
sobre deixar Windows 2000, o qual parecia cair no esquecimento. Sistemas com
<tt class="docutils literal">COMSPEC</tt> a <tt class="docutils literal">command.com</tt> também estavam em processo de perda de suporte.
<a class="reference external" href="http://hg.python.org/peps/rev/b9390aa12855">A partir de agora</a> 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.</p>
<p>De maneira a começar a deixar de suportar estes sistemas, estamos modificando a <a class="reference external" href="http://www.python.org/dev/peps/pep-0011/">PEP 11</a>.</p>
<div class="section" id="pep-11">
<h4>PEP 11</h4>
<p>Esta PEP delineia os sistemas operacionais que não são mais suportados e
explica qual o processe de se adicionar um SO à lista.</p>
<p>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.</p>
<p>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 "<a class="reference external" href="http://docs.python.org/dev/whatsnew/3.3.html#unsupported-operating-systems">What's New</a>" com a lista dos sistemas não mais suportados.</p>
<p>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 <tt class="docutils literal">#ifdef</tt> e seções <tt class="docutils literal">configure</tt> obsoletos no código.</p>
</div>
<div class="section" id="o-que-voce-pode-fazer">
<h4>O que você pode fazer</h4>
<p>Se você é usuário de OS/2 ou VMS, algumas coisas podem ser feitas para salvar sua
plataforma.</p>
<div class="section" id="torne-se-mantenedor">
<h5>Torne-se mantenedor</h5>
<p>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
<a class="reference external" href="http://www.vmspython.org/">http://www.vmspython.org</a>, mas com tem sido discutido no <a class="reference external" href="http://bugs.python.org/issue11918">problema 11918</a>, alguém tem
de aparecer para manter o suporte a VMS.</p>
<p>Se você estiver interessado em assumir o desenvolvimento em uma das plataformas,
dê uma olhada no <a class="reference external" href="http://docs.python.org/devguide">developer's guide</a> e veja o processo de desenvolvimento atual.</p>
</div>
<div class="section" id="contribua-com-um-build-slave">
<h5>Contribua com um "build slave"</h5>
<p>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.</p>
<p>Python usa o <a class="reference external" href="http://trac.buildbot.net/">Buildbot</a> para uma integração contínua, e "build slaves" são
<a class="reference external" href="http://www.python.org/dev/buildbot/">fornecidos</a> 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 <a class="reference external" href="http://mail.python.org/mailman/listinfo/python-dev">python-dev</a>.</p>
</div>
</div>
<div class="system-messages section"><div class="system-message" id="id2">
</div>
</div>
</div>Anonymoushttp://www.blogger.com/profile/12361293458447621754noreply@blogger.com0tag:blogger.com,1999:blog-728465981741457530.post-39664909695238706062011-06-01T11:14:00.002-04:002011-06-01T11:15:39.518-04:00Projeto de Tradução do Python Insider<div class="document" id="projeto-de-traducao-do-python-insider">
<p>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: <a class="reference external" href="http://blog-ja.python.org/">Japonês</a> e <a class="reference external" href="http://blog-es.python.org/">Espanhol</a>.</p>
<p>As traduções estarão um pouco atrasadas no começo em relação ao
<a class="reference external" href="http://blog.python.org/">Python Insider</a>, mas tentaremos atualizá-las.</p>
<div class="section" id="precisa-se-de-ajuda">
<h4>Precisa-se de ajuda</h4>
<p>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).</p>
</div>
</div>Anonymoushttp://www.blogger.com/profile/12361293458447621754noreply@blogger.com0tag:blogger.com,1999:blog-728465981741457530.post-11572104651169472252011-05-31T13:08:00.002-04:002011-05-31T13:08:32.492-04:00Conheça a Equipe: Brian Curtin<div class="document" id="conheca-a-equipe-brian-curtin">
<p><em>Esta postagem é parte da série "Conheça a Equipe", a qual tem a intenção
de apresentar a equipe de desenvolvimento Python.</em></p>
<table class="docutils field-list" frame="void" rules="none"><colgroup><col class="field-name"></colgroup><colgroup><col class="field-body"></colgroup><tbody valign="top"><tr class="field"><th class="field-name">Nome:</th><td class="field-body">Brian Curtin</td></tr><tr class="field"><th class="field-name">Localização:</th><td class="field-body">Chicago, IL</td></tr><tr class="field"><th class="field-name">Página:</th><td class="field-body"><a class="reference external" href="http://blog.briancurtin.com/">http://blog.briancurtin.com/</a></td></tr></tbody></table>
<p><strong>Há quanto tempo você usa Python?</strong></p>
<p>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.</p>
<p><strong>Há quanto tempo você tem desenvolvido para a linguagem?</strong></p>
<p>Há pouco mais de um ano. No dia 24 de Março completo um ano com o grupo.</p>
<p><em>Como você começou como desenvolvedor do núcleo de Python? Você se lembra da sua primeira contribuição?*</em></p>
<p>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.</p>
<p>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.</p>
<p><strong>Em quais partes de Python você está trabalhando no momento?</strong></p>
<p>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.</p>
<p><strong>Você utiliza Python para que quando não está trabalhando no núcleo da linguagem?</strong></p>
<p>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.</p>
<p><strong>O que você gosta de fazer quando não está programando?</strong></p>
<p>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.</p>
</div>Anonymoushttp://www.blogger.com/profile/12361293458447621754noreply@blogger.com0tag:blogger.com,1999:blog-728465981741457530.post-32507755882129564532011-05-31T12:48:00.002-04:002011-05-31T12:48:59.076-04:00Conheça a Equipe: Nick Coghlan<div class="document" id="conheca-a-equipe-nick-coghlan">
<p><em>Esta postagem é parte da série "Conheça a Equipe", a qual tem a intenção
de apresentar a equipe de desenvolvimento Python.</em></p>
<table class="docutils field-list" frame="void" rules="none"><colgroup><col class="field-name"></colgroup><colgroup><col class="field-body"></colgroup><tbody valign="top"><tr class="field"><th class="field-name">Nome:</th><td class="field-body">Nick Coghlan</td></tr><tr class="field"><th class="field-name">Localização:</th><td class="field-body">Brisbane, Australia</td></tr><tr class="field"><th class="field-name">Página:</th><td class="field-body"><a class="reference external" href="http://www.boredomandlaziness.org/">http://www.boredomandlaziness.org</a></td></tr></tbody></table>
<p><strong>Há quanto tempo você usa Python?</strong></p>
<p>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.</p>
<p><strong>Há quanto tempo você tem desenvolvido para a linguagem?</strong></p>
<p>Guido me deu acesso em 2005 para atualizar a PEP 343 (para remover o "context method")</p>
<p><em>Como você começou como desenvolvedor do núcleo de Python? Você se lembra da sua primeira contribuição?*</em></p>
<p>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.</p>
<p>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.</p>
<p><strong>Em quais partes de Python você está trabalhando no momento?</strong></p>
<p>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.</p>
<p><strong>Você utiliza Python para que quando não está trabalhando no núcleo da linguagem?</strong></p>
<p>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.</p>
<p><strong>O que você gosta de fazer quando não está programando?</strong></p>
<p>Tae kwon do, vídeo games, futebol, leitura, etc, etc...</p>
</div>Anonymoushttp://www.blogger.com/profile/12361293458447621754noreply@blogger.com0tag:blogger.com,1999:blog-728465981741457530.post-25754541311381318462011-05-30T12:42:00.002-04:002011-05-30T12:43:05.128-04:00Novo Design para o Blog<div class="document" id="novo-design-para-o-blog">
<p>Se você lê o Python Insider através de um leito de "feeds", talvez você
não tenha visto o novo design que <a class="reference external" href="http://twitter.com/sigviper">Marcin Wojtczuk</a> 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.</p>
<p>Obrigado pelo tempo e esforço, Marcin!</p>
</div>Anonymoushttp://www.blogger.com/profile/12361293458447621754noreply@blogger.com0tag:blogger.com,1999:blog-728465981741457530.post-79873506452136973612011-05-30T12:03:00.002-04:002011-05-30T12:29:07.625-04:00Correção da vulnerabilidade de segurança do urllib/urllib2<div class="document" id="correcao-da-vulnerabilidade-de-seguranca-do-urllib-urllib2">
<p>Guido van Rossum <a class="reference external" href="http://hg.python.org/cpython/rev/a778b963eae3">publicou recentemente uma correção</a> 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.</p>
<div class="section" id="relatar-um-problema">
<h4>Relatar um problema</h4>
<p>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.</p>
<p>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 <a class="reference external" href="mailto:security@python.org">security@python.org</a>.</p>
<p>Niels Heinen, da Equipe de Segurança do Google, recentemente <a class="reference external" href="http://bugs.python.org/issue11662#msg131981">enviou um bom relatório</a>.
Ele descobriu um problema com o gerenciamento de redirecionamentos 302 do HTTP, nos módulos
<a class="reference external" href="http://docs.python.org/library/urllib">urllib</a> e <a class="reference external" href="http://docs.python.org/library/urllib2">urllib2</a> 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.</p>
<p>Primeiramente, já que <tt class="docutils literal">urllib</tt>/<tt class="docutils literal">urllib2</tt> definem um gerenciamento para o esquema
de URL <tt class="docutils literal"><span class="pre">file://</span></tt>, um redirecionamento para <tt class="docutils literal"><span class="pre">file:///etc/passwd</span></tt> poderia expor dados
de senhas. Niels também explicou que redirecionamentos para um dispositivo do tipo
<tt class="docutils literal"><span class="pre">file:///dev/zero</span></tt> poderia levar a um problema de "denial of service"</p>
</div>
<div class="section" id="recebimento-de-relatorios">
<h4>Recebimento de Relatórios</h4>
<p>Dada a confidencialidade de relatórios de segurança, a lista <a class="reference external" href="mailto:security@python.org">security@python.org</a>
é 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 <a class="reference external" href="http://www.python.org/news/security/">security news</a> para detalhes
a respeito do OpenPGP.</p>
<p>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 <a class="reference external" href="http://bugs.python.org/issue11662">problema #11662</a>, completo com "patch" inicial.</p>
</div>
<div class="section" id="consertando-o-problema">
<h4>Consertando o Problema</h4>
<p>O "patch" de Guido restringiu os redirecionamentos de URL <tt class="docutils literal"><span class="pre">http://</span></tt>, <tt class="docutils literal"><span class="pre">https://</span></tt>,
e <tt class="docutils literal"><span class="pre">ftp://</span></tt>. 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.</p>
<p>Em Python 2.x, o método <tt class="docutils literal">redirect_internal</tt> do <a class="reference external" href="http://docs.python.org/library/urllib#urllib.FancyURLopener">FancyURLopener</a> agora mostra
um <tt class="docutils literal">IOError</tt> quando o redirecionamento é inapropriado. Em <a class="reference external" href="http://docs.python.org/library/urllib2#httpredirecthandler-objects">HTTPRedirectHandler</a>,
<tt class="docutils literal">http_error_302</tt> faz a mesma coisa, só que apresentando <tt class="docutils literal">HTTPError</tt>. Em Python 3,
<a class="reference external" href="http://docs.python.org/dev/library/urllib.request">urllib.request</a> recebeu as mesmas modificações. Incluídos no "patch" estão dois
testes que testam redirecionamentos para esquemas válidos e inválidos.</p>
<p>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.</p>
</div>
</div>Anonymoushttp://www.blogger.com/profile/12361293458447621754noreply@blogger.com0tag:blogger.com,1999:blog-728465981741457530.post-44028419688760537122011-05-20T10:06:00.002-04:002011-05-20T10:06:25.262-04:00Conheça a Equipe: Tarek Ziadé<div class="document" id="conheca-a-equipe-tarek-ziade">
<p><em>Esta postagem é parte da série "Conheça a Equipe", a qual tem a intenção
de apresentar a equipe de desenvolvimento Python.</em></p>
<p><strong>Há quanto tempo você usa Python?</strong></p>
<p>Há cerca de 10 anos.</p>
<p><strong>Há quanto tempo você tem desenvolvido para a linguagem?</strong></p>
<p>Desde 21 de dezembro de 2008.</p>
<p><em>Como você começou como desenvolvedor do núcleo de Python? Você se lembra da sua primeira contribuição?*</em></p>
<p>Eu iniciei meu trabalho como desenvolvedor do núcleo para realizar a manutenção do Distutils e
melhorá-lo.</p>
<p>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.</p>
<p>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.</p>
<p><strong>Em quais partes de Python você está trabalhando no momento?</strong></p>
<p>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.</p>
<p><strong>Você utiliza Python para que quando não está trabalhando no núcleo da linguagem?</strong></p>
<p>Eu trabalho para a Mozilla, na equipe de serviços, aonde faço serviços web com Python.</p>
<p><strong>O que você gosta de fazer quando não está programando?</strong></p>
<p>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.</p>
</div>Anonymoushttp://www.blogger.com/profile/12361293458447621754noreply@blogger.com0tag:blogger.com,1999:blog-728465981741457530.post-89886093928835087212011-05-19T12:56:00.002-04:002011-05-19T12:56:38.153-04:00Formalização da Política de Controle de Mudanças na AST<div class="document" id="formalizacao-da-politica-de-controle-de-mudancas-na-ast">
<p>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 <a class="reference external" href="http://docs.python.org/py3k/library/ast.html">módulo AST</a>.
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.</p>
<p>Embora o significado do código Python é definido por uma <a class="reference external" href="http://docs.python.org/py3k/reference/index.html">referência de linguagem</a>,
o módulo AST é uma implementação em CPython, e implementações em outros tipos de Python não é necessária.</p>
<div class="section" id="compatibilidade-do-ast">
<h4>Compatibilidade do AST</h4>
<p>Como parte do <a class="reference external" href="http://bugs.python.org/issue11549">trabalho</a> 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 <a class="reference external" href="http://mail.python.org/pipermail/python-dev/2011-April/110399.html">perguntou</a>
na lista python-dev: "Seria necessário compatibilidade reversa para alterações no AST?".</p>
<p>O consenso geral foi de que tal compatibilidade <em>não</em> era necessária. O módulo AST
expõe uma constante, <tt class="docutils literal">ast.__version__</tt>, 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.</p>
</div>
<div class="section" id="outras-implementacoes-de-python">
<h4>Outras implementações de Python</h4>
<p>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 <tt class="docutils literal">ast.__version__</tt>
mude, já que o AST poderia ser modificado de maneira incompatível.</p>
<p>Um ponto que foi levantado é que um pacote de testes complete em <tt class="docutils literal">test_ast.py</tt>
ajudaria outras implementações, fazendo que fosse certificado que as representações de
AST sejam compatíveis com CPython. Aumentar a abrangência de <tt class="docutils literal">test_ast.py</tt> seria
um excelente projeto para alguém interessado em se envolver com Python.</p>
</div>
<div class="section" id="e-agora">
<h4>E agora?</h4>
<p>Um <a class="reference external" href="http://bugs.python.org/issue11549">"patch"</a>, 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 <em>vai</em> ser alterado de uma maneira compatível.
A constante <tt class="docutils literal">ast.__version__</tt> 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.</p>
<p>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 <a class="reference external" href="http://mail.python.org/pipermail/python-dev/2011-April/110399.html">python-dev</a>.</p>
</div>
</div>Anonymoushttp://www.blogger.com/profile/12361293458447621754noreply@blogger.com0tag:blogger.com,1999:blog-728465981741457530.post-2022591449653739302011-05-17T09:46:00.002-04:002011-05-17T09:46:40.217-04:00Thomas Heller não é mais o mantenedor de ctypes<div class="document" id="thomas-heller-nao-e-mais-o-mantenedor-de-ctypes">
<p>A comunidade de desenvolvimento de Python agradece em muito o longevo
mantenedor de <a class="reference external" href="http://docs.python.org/library/ctypes">ctypes</a>, Thomas Heller. Há algum tempo, Thomas anunciou
que estava deixando o projeto CPython, o lar da sua biblioteca <tt class="docutils literal">ctypes</tt>
desde Python 2.5.</p>
<p>Tivemos uma oportunidade de conversar com Thomas, aonde ele nos contou sua
história com Python e seus projetos <tt class="docutils literal">ctypes</tt> e <tt class="docutils literal">py2exe</tt>.</p>
<div class="section" id="python">
<h4>Python</h4>
<p>Em 1999, Thomas buscava maneiras de aprender Python, encontrou <a class="reference external" href="http://www.amazon.com/Programming-Python-Mark-Lutz/dp/0596009259">Programming Python</a>
de Mark Lutz, e ficou fascinado com a linguagem. Naquele tempo ele também
estava tentando substituir <a class="reference external" href="http://groups.csail.mit.edu/mac/projects/scheme/">Scheme</a> nas extensões de C para uma programa
que ele desenvolvia no momento.</p>
<p>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 <tt class="docutils literal">distutils</tt> para Windows. O seu interesse com <tt class="docutils literal">distutils</tt>,
o levou a criação do comando <tt class="docutils literal">bdist_wininst</tt> 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.</p>
</div>
<div class="section" id="py2exe">
<h4>py2exe</h4>
<p>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 <tt class="docutils literal">squeeze</tt> de Fredrik Lundh e
<tt class="docutils literal">sqfreeze</tt> de Christian Tismer, além de alguns "patches" que Thomas contribuiu
para o projeto <a class="reference external" href="http://davidf.sjsoft.com/mirrors/mcmillan-inc/install1.html">Installer</a> de Gordon McMillan.</p>
<p>Seu interesse no <tt class="docutils literal">distutils</tt> levou Thomas a considerar transformar <tt class="docutils literal">Installer</tt>
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 <tt class="docutils literal">distutils</tt>.
No final, ele escolheu um nome simples mas bem descritivo para o projeto: <tt class="docutils literal">py2exe</tt>.</p>
</div>
<div class="section" id="ctypes">
<h4>ctypes</h4>
<p>A ideia para <tt class="docutils literal">ctypes</tt> veio de uma necessidade de se ir além daquilo que <a class="reference external" href="http://sourceforge.net/projects/pywin32/">pywin32</a>
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.</p>
<p><tt class="docutils literal">ctypes</tt> 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 <a class="reference external" href="http://python.net/crew/theller/">Starship</a>, mas
transformou-se em uma biblioteca largamente usada em pouco tempo.</p>
<p>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 <a class="reference external" href="http://sourceware.org/libffi/">libffi</a>, a qual ele também passou a usar em Windows
para substituir sua implementação de baixo-nível.</p>
<p>2006 foi marcado pela versão 1.0 de <tt class="docutils literal">ctypes</tt>, 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, <tt class="docutils literal">ctypes</tt> finalmente havia sido incorporada a Python
e disponível para uma audiência muito maior.</p>
<p>Muitas pessoas contribuíram para que <tt class="docutils literal">ctypes</tt> 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.</p>
</div>
<div class="section" id="um-novo-mantenedor-para-ctypes">
<h4>Um novo mantenedor para ctypes</h4>
<p>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 <a class="reference external" href="http://docs.python.org/devguide">guia de desenvolvimento</a>
e veja a list de bugs para maiores informações.</p>
</div>
</div>Anonymoushttp://www.blogger.com/profile/12361293458447621754noreply@blogger.com0tag:blogger.com,1999:blog-728465981741457530.post-64853715416493578522011-05-13T14:49:00.005-04:002011-05-20T09:59:37.137-04:00Conheça a Equipe: Benjamin Peterson<div class="document" id="conheca-a-equipe-benjamin-peterson">
<p><em>Esta postagem é parte da série "Conheça a Equipe", a qual tem a intenção
de apresentar a equipe de desenvolvimento Python.</em></p>
<table class="docutils field-list" frame="void" rules="none"><colgroup><col class="field-name"></colgroup><colgroup><col class="field-body"></colgroup><tbody valign="top"><tr class="field"><th class="field-name">Nome:</th><td class="field-body">Benjamin Peterson</td></tr><tr class="field"><th class="field-name">Lugar:</th><td class="field-body">Minnesota, USA</td></tr><tr class="field"><th class="field-name">Home Page:</th><td class="field-body"><a class="reference external" href="http://benjamin-peterson.org/">http://benjamin-peterson.org</a></td></tr><tr class="field"><th class="field-name">Blog:</th><td class="field-body"><a class="reference external" href="http://pybites.blogspot.com/">http://pybites.blogspot.com</a></td></tr></tbody></table>
<p><strong>Há quanto tempo você usa Python?</strong></p>
<p>Três anos e meio</p>
<p><strong>Há quanto tempo você tem desenvolvido para a linguagem?</strong></p>
<p>Exatamente há três anos no dia 25 de Março.</p>
<p><em>Como você começou como desenvolvedor do núcleo de Python? Você se lembra da sua primeira contribuição?*</em></p>
<p>Minha primeira proposta foi rejeitada pelo <a class="reference external" href="http://bugs.python.org/issue1828">próprio Guido</a>.
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.</p>
<p><strong>Em quais partes de Python você está trabalhando no momento?</strong></p>
<p>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!</p>
<p><strong>Você utiliza Python para que quando não está trabalhando no núcleo da linguagem?</strong></p>
<p>Eu uso para implementar um <a class="reference external" href="http://pypy.org/">interpretador de Python</a>. Eu sou
um implementador de Python coração :) . Eu fui o criador do <a class="reference external" href="http://pypi.python.org/pypi/six">six</a>,
uma biblioteca de compatibilidade entre as versões 2 e 3.</p>
<p><strong>O que você gosta de fazer quando não está programando?</strong></p>
<p>Compor, tocar clarineta, e ler livros de matemática. Às vezes, também faço trilhas.</p>
</div>Anonymoushttp://www.blogger.com/profile/12361293458447621754noreply@blogger.com0tag:blogger.com,1999:blog-728465981741457530.post-91647352979454184532011-05-12T10:56:00.000-04:002011-05-13T16:57:34.207-04:00Código obsoleto entre 2.7 e 3.2<div class="document" id="codigo-obsoleto-entre-2-7-e-3-2">
<p>Discussões recentes na lista <a class="reference external" href="http://mail.python.org/pipermail/python-dev/2011-March/109010.html">python-dev</a>
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.</p>
<div class="section" id="perspectiva">
<h4>Perspectiva</h4>
<p>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 <a class="reference external" href="http://www.python.org/dev/peps/pep-0005/">PEP 5</a>.
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.</p>
<p>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.</p>
</div>
<div class="section" id="linhas-de-desenvolvimento-paralelas">
<h4>Linhas de Desenvolvimento Paralelas</h4>
<p>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.</p>
<p>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.</p>
<p>Mas, existem alguns problemas ...</p>
</div>
<div class="section" id="obsolencias-surpresa">
<h4>Obsolências surpresa</h4>
<p>Em <a class="reference external" href="http://mail.python.org/pipermail/python-dev/2011-March/109010.html">uma discussão da python-dev</a>,
um participante apontou para o fato de que uma função específica da API C, <tt class="docutils literal">PyCObject_AsVoidPtr</tt>, 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?</p>
<p>A alteração fazia parte de uma mudança maior, da API antiga (<tt class="docutils literal">PyCObject</tt>)
para uma nova e melhor (<tt class="docutils literal">PyCapsule</tt>). O problema é <tt class="docutils literal">PyCObject</tt> é 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 <tt class="docutils literal">PyCapsule</tt> 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.</p>
<p>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.</p>
</div>
<div class="section" id="o-que-fazer">
<h4>O que fazer?</h4>
<p>Mesmo que o caso <tt class="docutils literal">PyCObject</tt>/<tt class="docutils literal">PyCapsule</tt> 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.</p>
<p>No caso específico do <tt class="docutils literal">PyCObject</tt>/<tt class="docutils literal">PyCapsule</tt>, o problema já existe e não há muito o que se fazer.
Reintroduzir <tt class="docutils literal">PyCObject</tt> 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, <tt class="docutils literal">PyCObject</tt> foi escrito encapsulando a API <tt class="docutils literal">PyCapsule</tt>. 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.</p>
<p>Em termos gerais, a equipe de desenvolvedores Python já está consciente do problema
e vai trabalhar para evitar que isso ocorra novamente. Guido <a class="reference external" href="http://mail.python.org/pipermail/python-dev/2011-March/109450.html">deu sua opinião</a> 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.</p>
<p>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.</p>
</div>
<div class="section" id="qual-o-significado-disso-tudo">
<h4>Qual o significado disso tudo?</h4>
<p>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.</p>
<p>Além disso, consertar o problema pode acarretar mais problemas do que solucioná-los, fazendo
com que a API <tt class="docutils literal">PyCObject</tt> 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.</p>
<p>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.</p>
<p>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.</p>
</div>
</div>Anonymoushttp://www.blogger.com/profile/12361293458447621754noreply@blogger.com0tag:blogger.com,1999:blog-728465981741457530.post-2380353759110551532011-05-08T16:33:00.003-04:002011-05-08T16:36:20.184-04:00Sobre polling, futuros e execução em paralelo<div class="document" id="sobre-polling-futuros-e-execucao-em-paralelo">
<p>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.</p>
<p>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 <a class="reference external" href="http://www.lesswatts.org/projects/applications-power-management/avoid-pulling.php">Intel parece preocupada</a>..</p>
<p>Python 3.2 apresenta um novo módulo padrão que inicia tarefas concomitantes e as espera
terminar: o <a class="reference external" href="http://docs.python.org/dev/library/concurrent.futures.html">módulo concurrent.futures</a>.
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 <a class="reference external" href="http://docs.python.org/dev/library/concurrent.futures.html#concurrent.futures.ThreadPoolExecutor">ThreadPoolExecutor</a> e
<a class="reference external" href="http://docs.python.org/dev/library/concurrent.futures.html#concurrent.futures.ProcessPoolExecutor">ProcessPoolExecutor</a>.
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.</p>
<p>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.</p>
<p>Desta maneira, apresentamos uma <a class="reference external" href="http://bugs.python.org/issue11635">solução bem simples</a>:
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.</p>
<p>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, <a class="reference external" href="http://docs.python.org/dev/library/multiprocessing.html#multiprocessing.Queue.get">multiprocessing.Queue.get()</a>
com um contador diferente de zero e não infinito usa ... "polling" (por o qual, abrimos o <a class="reference external" href="http://bugs.python.org/issue11668">problema 11668</a>). 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.</p>
<p>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.</p>
<p>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 <a class="reference external" href="http://bugs.python.org/issue7316">número 7316</a>.</p>
</div>Anonymoushttp://www.blogger.com/profile/12361293458447621754noreply@blogger.com0tag:blogger.com,1999:blog-728465981741457530.post-70534553855094710042011-05-06T11:32:00.002-04:002011-05-06T11:33:57.563-04:00Atualizações do Language Summit 2011<div class="document" id="atualizacoes-do-language-summit-2011">
<p>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 <a class="reference external" href="http://www.python.org/">CPython</a>, <a class="reference external" href="http://www.pypy.org/">PyPy</a>, <a class="reference external" href="http://www.jython.org/">Jython</a>,
<a class="reference external" href="http://www.ironpython.net/">IronPython</a>, e <a class="reference external" href="http://www.parrot.org/">Parrot</a> VMs; mantenedores de distribuições Linux <a class="reference external" href="http://www.fedoraproject.org/">Fedora</a>, <a class="reference external" href="http://www.ubuntu.com/">Ubuntu</a>, e <a class="reference external" href="http://www.debian.org/">Debian</a>;
desenvolvedores do projecto <a class="reference external" href="http://www.twistedmatrix.com/">Twisted</a>, dentre outros, estiveram presentes.</p>
<div class="section" id="blog-dos-desenvolvedores">
<h4>Blog dos Desenvolvedores</h4>
<p>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.</p>
<p>Qualquer implementação de Python poderá postar no Insider. Por exemplo, mesmo que
PyPy já <a class="reference external" href="http://morepypy.blogspot.com/">tenha um blog em atividade</a>, os seus desenvolvedores
são bem-vindos para postar aqui. Implementações de Python alternativas serão incluídas na <a class="reference external" href="http://python.org/download">página de download da
python.org</a>, graças a discussões em paralelo. Novas versões também serão anunciadas
na página inicial em <a class="reference external" href="http://www.python.org/">python.org</a>.</p>
</div>
<div class="section" id="avisos-de-compatibilidade">
<h4>Avisos de Compatibilidade</h4>
<p>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.</p>
<p>A ideia surgiu de um bug no CPython relatado pelos desenvolvedores de PyPy.
No <a class="reference external" href="http://bugs.python.org/issue11455">Issue #11455</a> é mostrado um problema
onde CPython permite que um usuário crie um type com chaves que não são strings no
<tt class="docutils literal">__dict__</tt>, 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.</p>
</div>
<div class="section" id="biblioteca-padrao-autonoma">
<h4>Biblioteca Padrão Autônoma</h4>
<p>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.</p>
<p>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.</p>
<p>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>
</div>
<div class="section" id="pagina-da-velocidade-de-execucao">
<h4>Página da Velocidade de Execução</h4>
<p>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.</p>
<p>Foi sugerido a alocação de algumas máquinas de alta capacidade (high-performance) no
<a class="reference external" href="http://osuosl.org/">Open Source Lab da Oregon State University</a>, 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!</p>
<p>Se você ou sua organização estiverem interessados em fazer uma doação, por favor entre em
contato com a <a class="reference external" href="http://www.python.org/psf/about">Python Software Foundation</a> e acesse a
<a class="reference external" href="http://www.python.org/psf/donations">página de doações</a>.</p>
</div>
<div class="section" id="termino-da-moratoria">
<h4>Término da Moratória</h4>
<p>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.</p>
<p>Com relação a mudanças na linguagem na versão 3.3, fiquem atentos a <a class="reference external" href="http://www.python.org/dev/peps/pep-0380/">PEP 380</a>,
a qual já foi aceita. Esta PEP introduz uma nova sintaxe <tt class="docutils literal">yield from <expr></tt>, permitindo que
o generator <tt class="docutils literal">yield</tt> um outro generator. À exceção disso, nenhuma outra mudança na linguagem é esperada.</p>
</div>
<div class="section" id="atributos-de-excecoes">
<h4>Atributos de exceções</h4>
<p>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.</p>
<p>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 <a class="reference external" href="http://bugs.python.org/issue8754">ImportError</a>.</p>
</div>
<div class="section" id="acordos-de-contribuicao">
<h4>Acordos de contribuição</h4>
<p>Acordos de contribuição também foram mencionados, sendo que um formato eletrônico do acordo
está sendo produzido. O <a class="reference external" href="http://code.google.com/legal/individual-cla-v1.0.html">acordo de contribuição individual do Google</a>
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.</p>
</div>
<div class="section" id="google-summer-of-code">
<h4>Google Summer of Code</h4>
<p>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
<a class="reference external" href="http://pyfound.blogspot.com/2011/03/google-summer-of-code-call-for-projects.html">Call for Projects and Mentors</a>.</p>
</div>
<div class="section" id="distutils">
<h4>Distutils</h4>
<p>O tópico <a class="reference external" href="https://bitbucket.org/tarek/distutils2/wiki/Home">Distutils2</a> 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: <tt class="docutils literal">packaging</tt>. 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.</p>
<p>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
<a class="reference external" href="https://bitbucket.org/tarek/cpython">Bitbucket</a>, aguardando fusão com a biblioteca padrão.</p>
</div>
<div class="section" id="o-futuro-das-vms-alternativas">
<h4>O Futuro das VMs Alternativas</h4>
<p>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.</p>
<p>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.</p>
</div>
<div class="section" id="fomento-para-programacao">
<h4>Fomento para programação</h4>
<p>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.</p>
</div>
<div class="section" id="python-baseline-basico">
<h4>Python "Baseline" (básico)</h4>
<p>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.</p>
<p>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.</p>
<p>Aparentemente, ainda não há um consenso ou solução, mas os grupos envolvidos continuarão
a trabalhar na questão.</p>
</div>
<div class="section" id="recursos-3-3">
<h4>Recursos 3.3</h4>
<p>Algumas sugestões foram dadas com relação a versão 3.4, incluindo duas PEPs.
<a class="reference external" href="http://www.python.org/dev/peps/pep-0382">PEP 382</a>, 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.</p>
<p><a class="reference external" href="http://www.python.org/dev/peps/pep-0393">PEP 393</a>, 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.</p>
</div>
<div class="section" id="unladen-swallow">
<h4>Unladen Swallow</h4>
<p>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.</p>
<p>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.</p>
<p>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.</p>
</div>
<div class="section" id="criando-um-caminho-para-frameworks-assincronas">
<h4>Criando um caminho para frameworks assíncronas</h4>
<p>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.</p>
<p>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.</p>
</div>
<div class="section" id="mais-informacoes">
<h4>Mais informações</h4>
<p>Para maiores informações, acesse a notas <a class="reference external" href="http://www.boredomandlaziness.org/2011/03/python-language-summit-rough-notes.html">http://www.boredomandlaziness.org/2011/03/python-language-summit-rough-notes.html</a> e
destaques <a class="reference external" href="http://www.boredomandlaziness.org/2011/03/python-language-summit-highlights.html">http://www.boredomandlaziness.org/2011/03/python-language-summit-highlights.html</a>
de Nick Coghlan, desenvolvedor do CPython,</p>
</div>
</div>Anonymoushttp://www.blogger.com/profile/12361293458447621754noreply@blogger.com0tag:blogger.com,1999:blog-728465981741457530.post-1691786385590442312011-05-02T16:17:00.002-04:002011-05-02T16:21:49.793-04:00Bem-vindo ao Python Insider!<div class="document" id="bem-vindo-ao-python-insider">
<p><a class="reference external" href="http://blog.python.org/">Python Insider</a> é 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.</p>
<p>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.</p>
<p>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.</p>
<div class="section" id="como-participar">
<h4>Como participar</h4>
<p>Existem várias maneiras de seguir <a class="reference external" href="http://blog.python.org/">Python Insider</a>:</p>
<ul class="simple">
<li><a class="reference external" href="http://planet.python.org/">Planet Python</a></li>
<li><a class="reference external" href="http://blog.python.org/">Na rede</a></li>
<li><a class="reference external" href="http://feeds.feedburner.com/PythonInsider">Feed Atom/RSS</a></li>
<li><a class="reference external" href="http://twitter.com/PythonInsider">@PythonInsider</a> no Twitter (en inglês)</li>
<li><a class="reference external" href="http://feedburner.google.com/fb/a/mailverify?uri=PythonInsider&loc=en_US">Correio eletrônico</a></li>
</ul>
</div>
<div class="section" id="procura-se-ajuda">
<h4>Procura-se ajuda</h4>
<p>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.</p>
<p>Para maiores informações, entre em contato com Doug Hellmann (doug dot hellmann no gmail).</p>
</div>
</div>Anonymoushttp://www.blogger.com/profile/12361293458447621754noreply@blogger.com0