Blog

Desde antes do Linux surgir ou da idéia de Software Livre ser conhecida entre as pessoas aqui no Brasil eu já era defensor deste modelo. Quando eu desenvolvia meus sistemas em Clipper para os meus clientes tratava logo de deixar o código fonte com eles e já deixava claro pra eles que se eles preferissem entregar a manutenção para outro desenvolvedor eles estariam livres para fazê-lo.

Discurso padrão: serei um pouco contundente em alguns trechos deste artigo. Farei algumas generalizações para facilitar mas, acredite, alguns brasileiros simplesmente não se encaixam no público alvo deste artigo.

Ok, essas liberdades que eu dava para meus clientes não chegavam nem perto das reais liberdades que os softwares licenciados pela GPL, por exemplo, oferecem hoje. Mas as minhas intenções eram as mesmas.

Desde que entrei de cabeça neste universo livre percebi que todos esses softwares que existem hoje foram ao menos iniciados a partir de esforços voluntários de uma comunidade de desenvolvedores, artistas, documentadores, etc.

Esses voluntários estão espalhados por todos os lugares do mundo inclusive no Brasil. E é sobre a participação brasileira que gostaria de comentar.

Atendendo à um pedido de um colega de trabalho comecei a fazer uma pequena pesquisa informal e não-científica sobre a participação de brasileiros no desenvolvimento de software livre e fiquei muito feliz em ver que esses brasileiros contribuem com vários projetos. Obviamente ainda é uma fração praticamente irrisória de contribuições se compararmos com países da europa, por exemplo, mas já é alguma coisa.

Essa pequena pesquisa também serviria para coletar alguns nomes de profissionais que fizeram alguma colaboração com código para algum desses projetos para buscar alguns talentos para vir trabalhar comigo na mesma empresa onde trabalho.

Aí veio a decepção. Infiltrando mais à fundo nas colaborações desses brasileiros foi possível notar que a contribuição nossa com código para esses projetos é tão pequena que faz qualquer um ficar decepcionado.

É claro que contribuir com documentação, traduções, arte, divulgação e uso é importante para esses projetos. Mas e o código? Software Livre não se cria sozinho! Você não liga um computador e o código pula na tela. Não é tão simples assim.

Sempre que eu falo que precisamos colaborar com código para os projetos já escuto logo um: “ah… mas eu traduzi o sistema foobar para o português!” ou “eu fiz um tutorial de instalação da distro ble”. Legal. Parabéns! Mas e aquele bug aberto no bugtrack do sistema foobar? E aquela funcionalidade que as pessoas estão implorando (inclusive você)?

Vamos esperar até o dia que o bug se feche sozinho? Ou que o desenvolvedor principal do projeto use o tempo dele para melhorar a minha vida?

Chegou a hora de parar de nos desculpar por não contribuir com código para os projetos simplesmente porque “eu traduzi as mensagens de erro do kernel!” e começar a anexar patches e fazer commits nesses projetos.

Eu me incluo entre esses “colaboradores de meia pataca”. Procurei pelo meu nome no Code Search do Google e achei um horror o resultado. Afinal já fazem mais de 6 anos que lido com Software Livre e meu nome apareceu em apenas algumas dezenas de ocorrências e, pior, em menos de uma dezena delas a minha contribuição tinha sido com código.

Então eu gostaria de lançar o desafio aqui: vamos todos repetir uma busca por nossos nomes no Google Search daqui a algum tempo e vamos ao menos dobrar o número de ocorrências deles por lá? Mas só vale contar contribuições com código!

Propaganda: Se você quer contribuir com código e quer começar por uma linguagem fácil e poderosa eu já recomendo à você que dê uma olhada na linguagem Python 🙂

Ao começar a trabalhar no desenvolvimento do Python para Maemo no INdT a gente percebeu que o CPython não apresentava problemas sérios de performance no 770 e que uma das poucas coisas que realmente incomodava era a demora para importar alguns módulos importantes na plataforma (principalmente o PyGTK).

Quando iniciamos a segunda fase do nosso projeto decidimos atacar a otimização da plataforma Python em duas frentes: uma na linha de pesquisa que daria resultados a longo prazo e uma outra com foco mais prático no CPython.

Eu assumi a segunda linha enquanto o Rafael Espíndola, que trabalha com a gente, assumiu a linha mais acadêmica (além de me dar uma ajuda valiosa com alguns testes que requerem mais conhecimento técnico). Esse trabalho envolve a criação de um backend ARM para o LLVM e posteriormente melhorar o backend LLVM do PyPy para que com essas duas ferramentas seja possível gerar código binário nativo para ARM a partir de código fonte Python.
Como o maior problema de performance do CPython no 770 era relacionado ao carregamento de módulos resolvi atacá-lo primeiro e para atacá-lo fui entender como ele funcionava. Não gostei muito do que vi.

Aparentemente o sistema de ‘import’ do Python nunca recebeu uma atenção muito grande e desde o começo ele vem recebendo patches em cima de patches. Muitas funcionalidades foram adicionadas sem muito planejamento ou, por manter compatibilidade retroativa, tiveram implementações pouco elegantes.

Decidi então fazer uma reforma nesse sistema tentando deixá-lo mais elegante e ao mesmo tempo não tentar quebrar compatibilidade retroativa gratuitamente.

Como estou interessado nessa parte do desenvolvimento do CPython eu me ofereci para ajudar o Brett Canon em uma das tarefas propostas para o Python Google Sprint. Infelizmente o Brett tinha outras prioridades para esse Sprint e pode se oferecer apenas para me ajudar quando eu precisasse. O Guido, por sua vez, também pediu para eu adicionar meu nome na tarefa.

Durante o período do Sprint eu desenvolvi um esboço (bem inicial, incompleto e agora totalmente perdido em algum backup velho.) do que eu planejava para que eles pudessem entender que rumo eu gostaria de seguir.

Mostrei o meu trabalho para o Brett e ele me diz que o que ele planejava era algo bem mais simples que serviria já para o 2.6 e consistia apenas em reescrever a função __import__() em Python e que o meu plano era maior e certamente não seria aceito para a série 2.6.

Me apontou também a PEP-302 onde algumas das minhas idéias já foram discutidas e não foram aceitas (principalmente por adicionarem incompatibilidade retroativa). E disse que como os nossos planos eram muito diferente ele iria trabalhar nos planos dele mas que continuaria me ajudando se eu precisasse.

A sensação que eu tenho é a de que eu devo seguir adiante com esse plano meu nem que seja para facilitar o nosso trabalho no Python para Maemo. Depois que tudo estiver pronto e funcionando eu vou escrever uma PEP e submeter na lista python-3k.

Se for aceito, legal. Se não for, paciência. Só espero que eles entendam o que eu quero com esse projeto e não façam como fizeram com o Gustavo Niemeyer quando ele propôs a inclusão do dateutil na biblioteca padrão do Python (por não terem entendido a proposta do módulo optaram por miná-la ao invés de entendê-la).

Trabalho na área de informática há muitos anos. Sempre trabalhei com desenvolvimento de software, exceto por um período de tempo quando tentei seguir a carreira de publicitário por estar um pouco decepcionado com o trabalho na área de programação de computadores.

A minha desilusão nasceu com o tipo de trabalho que um programador, aqui no Brasil, mais faz: software de gestão empresarial. A capacidade criativa que o brasileiro desenvolveu nesse tipo de desenvolvimento causa inveja em diversos países do mundo. Isso é bacana.

Esse tipo de desenvolvimento nunca foi meu preferido mas eu devo admitir que sempre foi o que fizemos de melhor.

Mas de um tempo para cá eu venho notado que as empresas de desenvolvimento de software estão procurando buscar modelos de desenvolvimento de software vindos de fora. Opa! Se esse é o tipo de coisa que sempre fizemos bem aqui não deveríamos estar exportando?

O modelo de empresa de desenvolvimento que me deixa mais horrorizado é o triunvirato formado por engenharia-de-software, fábrica-de-software, STLs (sigla-de-três-letras como CMM, RUP e PMI).

Quando eu estudava Processamento de Dados em um colégio técnico estadual no interior de São Paulo eu tinha vários amigos que estudavam ‘Edificações’ que forma profissionais preparados para auxiliar os Engenheiros Civis. Alguns alunos amigos meus eram tão bons em seus trabalhos que os engenheiros somente ‘assinavam’ os projetos feitos por eles.

Se nessa época a minha visão-além-do-alcance me mostrasse o que está acontecendo hoje eu iria estudar Edificações e não mais Processamento de Dados. Estou esperando o dia que vão surgir os decoradores de sistemas, afinal, os engenheiros de software e arquitetos de software já existem.

Esse triunvirato parte da premissa de que software é algo criado em cima de padrões, normas e requisitos e esquecem de que essas três coisas produzem software mas nunca irão produzir software fantástico. O que diferencia um software de um software fantástico é o ‘toque de genialidade’ dos desenvolvedores. É aquela modificação elegante no código que o torna mais eficiente. É aquela idéia simples que torna o sistema mais robusto. É aquele momento de inspiração que faz surgir um excelente software. É aquela fuga do padrão, da norma, e até mesmo do requisito que fazem um software virar um software fantástico.

Os softwares de gestão brasileiros são (eram?) fantásticos por essa razão. Antes as normas eram menos rígidas, os padrões menos abrangentes e os requisitos quase sempre eram desconhecido. Sei que muito software ruim foi produzido naquela época mas tolher a criatividade não deve ser a solução para esse problema. Que solução então? Seleção natural. É isso. Software ruim ‘morre’ com o passar do tempo. Software que nasce ruim mas melhora com o passar do tempo sobrevive.

Para resumir, o desenvolvimento de software é, em minha opinião, muito mais uma atividade criativa do que simplesmente aplicar técnicas, regras, normas em cima de um teclado de computador.

Minha forma de pensar leva à uma outra questão importante a ser ponderada: Programador sem criatividade deve mudar de profissão? Sim e não.

Se ele está nessa área porque disseram para ele que “programador é a profissão do futuro” sim. Todas as pessoas devem fazer o que gosta e não o que disseram para ela fazer. Trabalhar com algo que não te inspira cria pessoas tristes. E não vale falar que vai continuar programando porque ‘não agrada nem desagrada’, tem que gostar mesmo de trabalhar.

Mas se esse programador ‘não-criativo’ realmente tiver paixão pela profissão que vai exercer o problema de criatividade dele pode ser solucionado.

“Moço! Me vê 2kg de criatividade?”

As pessoas acham que um ‘insight criativo’ é o resultado de um sopro de pó de pirlim-pim-pim que a Fada Sininho jogou na gente. Isso não é totalmente verdade (exceto talvez pela fada).

Os ‘insights criativos’ são criados pelo nosso cérebro o tempo todo (em momentos randômicos). O nosso cérebro então coleta uma série de informações dos nossos ‘bancos de memórias’ de acesso rápido (informações), acesso lento (conhecimento) e do disco (lembranças), bate tudo por uns minutos no liquidificador e joga no ‘pipeline’ de coisas em processamento. O resultado dessa mistura, se for bom, será aproveitado, caso contrário será descartado imediatamente.

Com essa explicação podemos perceber que uma série de fatores aleatórios que determinam se você terá um ‘insight criativo’.

Quando você vai apostar na mega-sena (ou outro jogo desse tipo) você sabe que quanto mais números você marcar no canhoto de apostas maiores serão as suas chances de ganhar o prêmio. O mesmo acontece com nosso cérebro. Quanto mais informação, conhecimento e lembranças a gente tiver para que o nosso cérebro trabalhe maiores são as nossas chances de ter uma idéia legal.

E é aí que entra o fator ‘paixão’ pela profissão. Se você for apaixonado pelo que faz será mais fácil para você ler um livro sobre o assunto, fazer um treinamento, prestar atenção às informações relacionadas ao teu trabalho e assim por diante.

É claro que existem alguns programadores que são absurdamente geniais e criativos, mas eles são uma exceção (boa) e não são reproduzíveis em laboratório.

Tem que ter técnica!

Dizer que o importante é ser criativo não pode levar ninguém a concluir que a técnica é dispensável. Não é mesmo. A técnica é tão importante quanto a criatividade. Ambas devem ser desenvolvidas por igual e nutridas da mesma maneira. A técnica fornece elementos para que a loteria criativa do cérebro crie coisas legais que, através da técnica irão virar realidade; um ciclo fechado.

Não pense que Da Vinci usou só de criatividade para pintar a Monalisa. Se ele não tivesse conhecimento de sombras, luzes, cores, anatomia, etc. certamente ele não teria criado essa obra de arte.

É bastante provável que as pessoas que costumam ler esse blog já conheçam as minhas opiniões sobre o uso de Python no ensino de programação de computadores para alunos do ensino superior, mas como provavelmente eu nunca comentei nada por aqui, resolvi escrever este artigo.

Atualmente estou fazendo faculdade e tudo indica que dessa vez eu consigo terminá-la (diferente das outras 2e+35 tentativas anteriores). É uma faculdade daquelas formam “tecnólogos” em um curto espaço de tempo e essa me garante o direito de fazer uma pós-graduação stricto ou latu senso. Ainda estou no primeiro semestre e em minhas aulas de algorítmos tenho implementado alguns programinhas em “Portugol”.

A minha opinião sobre o uso de “Portugol” no primeiro semestre de um curso voltado para o desenvolvimento de software é -0, ou seja, não acho bom nem ruim, mas se usassem uma linguagem ‘de verdade’ tornaria o aprendizado um pouco mais divertido.

Portugol é legal quando o professor não disponibiliza um interpretador real da linguagem pois faz com que o aluno exercite a leitura de código e o entendimento do mesmo (o velho conhecido Teste de Mesa). O problema é que 6 meses de programação sem observar o efeito real dos programas não me parece ser muito ‘estimulante’.

Mas o foco desse artigo não é muito no primeiro semestre e no portugol. O foco deste artigo é mais adiante no curso onde estudaremos Delphi (como linguagem OO e orientada a eventos), Java (porque o mercado exige) e alguma linguagem estruturada que provavelmente será Pascal ou C (já que vi compiladores das duas linguagens nos laboratórios).

Em um passado não muito distante eu achava que os alunos deveriam aprender apenas Python por ser uma linguagem que aglutina vários paradigmas de programação (estruturado, OO e funcional). Usando apenas Python o professor “perderia” tempo para explicar a sintaxe de uma linguagem apenas uma única vez e, com isso, sobraria mais tempo para ele explicar esses diversos paradigmas.

A minha opinião só mudou (um pouco) após uma conversa com o Gustavo Niemeyer, enquanto voltávamos da I PyCon Brasil, onde ele me disse: “Um programador precisa saber como um computador funciona, como se aloca memória, como os dados são representados pelas máquinas. E esse tipo de coisa ele aprende se tiver que programar em C”. Fui obrigado a concordar com ele e, hoje, no meu trabalho vejo que isso realmente é muito importante. Esse tipo de coisa também pode ser aprendido programando-se em Assembly, mas todos sabemos que os professores não costumam dispor te tempo infinito para ensinar os alunos então C seria um meio-termo mais prático para eles (até por ser uma linguagem multiplataforma e algumas universidades terem acesso à diversas plataformas).

Depois de ter discutido isso com ele eu acho que cheguei à uma opinião menos extremada onde Python seria ensinada nos primeiros semestres (iniciando preferencialmente pelo paradigma OO) e um período de um ou dois semestres no final do curso serviriam para um intensivão de linguagem C.

Eu acho que o paradigma OO deve ser o primeiro a ser ensinado porque ele é mapeado de maneira muito simples ao mundo real que é comum à todos os egressos de um curso de programação. As pessoas sabem o que é um carro, um avião, um barco quando chegam à faculdade mas muito poucos alunos sabem separar dados e informações das ações que agem sobre estes. Mas essa opinião ainda não está escrita em pedra na minha cabeça porque ainda não tive acesso a resultados de estudos que comprovam que é mais fácil ensinar o paradigma OO ao estruturado. Isso é apenas uma intuição que tenho por ter achado muito difícil a minha migração do paradigma estruturado para o paradigma OO. Talvez o caminho inverso seja mais tranquilo.

A notícia (original em inglês) já não é tão nova assim mas Guido van Rossum, criador da linguagem Python, foi contratado para trabalhar no Google. Como alguns já sabem o Google é um dos maiores, mais antigos e mais importantes usuários da linguagem Python atualmente. O Google usa Python em diversas partes de seus sistemas como nos crawlers (procure por “Python”) e no sistema de Helpdesk deles (olhe a URL dessa página e veja o “.py”).

Segundo a notícia a contratação de Guido van Rossum mostra a importância que Python tem dentro do Google.

A outra notícia (que saiu no IDGNow!) é boa mas é ruim. Boa porque sempre é bom que uma empresa grande “abrace” uma linguagem de programação e dê apoio ao seu desenvolvimento. Ruim porque essa tal empresa que está abraçando a idéia de Python é conhecida por suas práticas desleais na área de tecnologia. Agora é aguardar, ver como as coisas vão desenrolar e torcer para que as intenções da Microsoft, pelo menos com relação à Python, sejam as melhores possíveis.

O legal dessa notícia é que ela também saiu na ‘grande imprensa’ tecnológica e não em um site do circuito de Software Livre onde as notícias sobre Python costumam circular. Esse já é uma dos bons efeitos colaterais que se obtêm quando uma grande empresa abraça a nossa causa.

A muitos anos atrás (tá, nem tantos assim) eu resolvi me aventurar com Zope. Eu era ‘garoto novo’ e bastante inexperiente com desenvolvimento OO. Me dei mal. Não sei se a coisa não rolou por causa dessa inexperiência ou porque Zope realmente era complicado. Mas o resultado foi: não deu.

Algum tempo depois fiquei mais experiente em OO e já me julgava capaz para fazer uma nova tentativa com o Zope. Modéstia à parte não sou um ‘toupeira’. Tenho uma experiência muito boa no desenvolvimento de Software e no trato com computadores e agora que já estava ‘afiado’ com desenvolvimento OO estava tudo indicando que dessa vez eu e o Zope teríamos um caso de amor.

Me adaptei super-rápido com o ZODB, super-mal com todo o resto. Não rolava desenvolver na Web e não gostei da idéia de guardar o código de minhas aplicações dentro do ZODB. Eu sei que ‘não gostei’ não é um argumento técnico muito forte mas mesmo assim abandonei o Zope porque achei que eu não era dígno de compreender a proposta dele.

Ganhei um treinamento ultra-fast-rápido com o Luciano Ramalho e continuei não gostando de algumas coisas.

Resolvi dar uma olhada no Plone e que era o melhor tipo de aplicação feita em cima do Zope que poderia existir. Assisti a uma apresentação sobre Archetypes e ArchgenXML proferida por caras que realmente souberam explicar o funcionamento deles.

Archetypes eu achei muito massa. ArchgenXML eu não gostei porque tenho ressalvas contra qualquer tipo de ferramenta que tente gerar código. A minha opinião pessoal é a de que a única ferramenta que consegue gerar código automaticamente se chama programador.

Aí chegou o Zope3 que simplesmente sumia com algumas das características que eu julgava indesejadas anteriormente. Parece que agora o ‘casamento’ sai.

Para tarefas triviais ainda é um canhão muito grande para matar pequenas moscas mas me parece que está se tornando uma boa ferramenta para desenvolver aplicações maiores.

Armei-me do que existe de melhor em termos de documentação sobre o Zope3 (até livros caros e importados) e estou atacando o dragão para desenvolver uma aplicação exemplo de controle de finanças pessoais (para meu uso). Tá saindo. Muito, mas muito mesmo, mais devagar do que se eu estivesse usando um framework mais ‘leve’ como um Turbogears ou o Django mas mesmo assim tá saindo.

Mas vou falar uma coisa: não é fácil. A facilidade de se aprender Zope é inversamente proporcional à facilidade de se aprender Python. Notei que sempre foi assim. Só estou conseguindo agora porque tenho muito mais experiência do que antes para tentar, mas se você está tentando aprender Zope agora não se ache um ‘burrão’ igual eu me achei no passado porque isso não é verdade. A verdade é que o Zope é um bicho muito difícil de domar mas depois de domado é o bicho mais poderoso que você pode ter em mãos.

Estou trabalhando na construção do pacote do Python 2.4.2 para a plataforma Maemo e uma das nossas missões nesse projeto é fazer com que os pacotes com o Python ocupem pouco espaço em disco. Essa missão vem do fato que a plataforma Maemo é projetada para dispositivos móveis que não costumam ser construídos com discos muito grande.

Para reduzir essa ocupação de espaço resolvemos distribuir apenas os módulos otimizados (.pyo) da biblioteca Python porque esses arquivos são menores que os seus equivalentes em código fonte (.py) que serão distribuídos em um pacote separado específico para desenvolvedores. Outra mudança que fizemos foi distribuir esses pacotes dentro de um arquivo .zip.

No entanto, descobrimos posteriormente que o FS do N770 já é comprimido e colocar os módulos dentro desse .zip se tornou desnecessário. Enquanto eu ‘tirava’ os módulos de dentro do ZIP eu esbarrei numa inconsistência no comportamento do CPython que vou ilustrar na seção abaixo:

1. Primeiramente eu crio dois módulos compilados. Um deles com otimização e o outro sem e adiciono os mesmos dentro de um ZIP:

$ ls
modulo_c.pyc  modulo_o.pyo
$ zip modulos.zip modulo_o.pyo modulo_c.pyc
  adding: modulo_o.pyo (deflated 38%)
  adding: modulo_c.pyc (deflated 38%)
$ ls
modulo_c.pyc  modulo_o.pyo  modulos.zip

2. Depois aciono o interpretador em modo normal (não-otimizado):

$ python2.4
>>> import modulo_c
modulo_c
>>> import modulo_o
ImportError: No module named modulo_o

Como puderam observar, o interpretador Python não procura arquivos com a extensão .pyo quando está em modo não-otimizado.

3. Na seqüência eu aciono o interpretador em modo otimizado:

$ python2.4 -O
>>> import modulo_c
ImportError: No module named modulo_c
>>> import modulo_o
modulo_o

E o comportamento inverso pode ser observado. O interpretador também não procura módulos .pyc quando está em modo otimizado.

4. Removo os módulos .pyc e .pyo para ficar com eles apenas dentro do Zip e repito os passos anteriores dizendo que o ‘modulos.zip’ agora faz parte do PYTHONPATH e deve servir de local para procura de módulos Python:

$ rm *.pyc *.pyo
$ ls
modulos.zip
$ PYTHONPATH=modulos.zip python2.4
>>> import modulo_c
modulo_c
>>> import modulo_o
modulo_o
$ PYTHONPATH=modulos.zip python2.4 -O
>>> import modulo_c
modulo_c
>>> import modulo_o
modulo_o

Aqui está a inconsistência. Utilizando o hook zipimport do Python ele procura por módulos .pyc e .pyo no PYTHONPATH. A única distinção que ele faz entre os dois modos é a de que no modo normal o interpretador procura na ordem “py->pyc->pyo” e no modo otimizado ele procura na ordem “py->pyo->pyc”.

Acho que essa inconsistência tem que ser eliminada e, em minha humilde opinião o comportamento do hook zipimport é mais adequado do que o do primeiro porque poderemos encontrar casos onde bibliotecas bytecode sejam fornecidas como .pyo e .pyc misturados (ok, eu sei que só renomear o arquivo já que o bytecode é o mesmo, mas não acho essa solução muito ‘elegante’).

Estou preparando um patch para deixar o comportamento do hook de importação padrão do Python funcione de maneira equivalente ao hook zipimport e vou submetê-lo para o projeto. Mas como esse patch tem uma solução baseada na minha visão eu gostaria de saber antes a opinião dos leitores: Qual dos 2 comportamentos deve permanecer? E, isso deve ser mudado?

Para quem tem acompanhado a lista de discussões Python Developers já deve ter percebido que as discussões sobre a versão 3 da linguagem Python vêm se intensificando a cada dia que passa.

Já foi dito a algum tempo atrás nessa mesma lista que a preocupação de manter compatibilidade retroativa com as versões atuais da linguagem Python serão praticamente nulas. Os desenvolvedores da linguagem se deram ao direito de quebrar essa compatibilidade para que finalmente eles possam corrigir erros de design que acompanham a linguagem desde as suas primeiras versões.

É importante que todos que usam Python intensivamente comecem a acompanhar essas discussões para já irem evitando certas ‘construções’ que não farão mais parte da linguagem no futuro. Existe uma quantidade considerável dessas ‘construções’, portanto, não vou ficar listando-as por aqui. Elas podem ser vistas em forma de propostas na PEP3000.

A sensação de acompanhar as discussões é: tensão. Eventualmente o Guido (BDFL) opta por algumas regras sintáticas e/ou construções na linguagem que me deixam consternados. Mesmo quando elas não passam apenas de propostas. Um caso recente foi quando ele sugeriu trocar os operadores lógicos “and”, “or” e “not” por “&&”, “||” e “!” como em linguagens com sintaxe baseadas na sintaxe da linguagem C.

Eu fiquei tenso por algumas horas até que várias pessoas votaram para que essa modificação não ocorresse. Eu fiquei preocupado porque eu gosto de ler uma expressão lógica como se estivesse lendo um parágrafo de um livro (if foo and bar:…) e não como se tivesse lendo uma tábua com hieroglífos (if foo && bar:…).

Outra sugestão que deram foi a de mudar o comportamento do retorno de expressões lógicas. Atualmente a linguagem Python usa um mecanismo de short-circuit para avaliar uma expressão lógica e o último elemento avaliado será retornado. Queriam que esse tipo de expressão retorne apenas “True” ou “False”. Acho que ambos comportamentos possuem vantagens e desvantagens e mudá-lo por mudar só faria com que mais código se quebrasse gerando erros realmente muito difíceis de encontrar. Ok, eu disse que já foi avisado que compatibilidade retroativa não é uma preocupação para o Py3, mas realmente é necessário quebrar compatibilidade com algo tão gratuito? Acho que não e parece que tem mais pessoas que pensam assim. A discussão saiu dessa linha de raciocínio e partiu para uma linha de proposta para criar um equivalente ao operador ternário da lingagem C (?:). Evidente que estão procurando uma sintaxe mais adequada do que a sintaxe usada pela linguagem C.

Eu gosto muito de Python e confio no julgamento do GvR para tomar decisões no desenho da linguagem, mas acompanhar as discussões na lista em tempos de mudanças tão grandes realmente não é indicado para programadores Python com coração fraco.

Em tempo: O pessoal do INdT e eu organizamos um pequeno “Planet” que ainda está hospedado em local temporário esperando pela liberação do domínio “maemo.org.br”. A versão provisória do Planet pode ser encontrada em “http://evolutum.gotdns.com/~osvaldo/planet/“.