Se esse Python fosse meu…

Apesar da aparente redundância dessa afirmação em um blog que se chama “Pythonologia” e escrito por um cara que faz propaganda de Python até pra sorveteiro. Mas eu prefiro ser redundante à não ser compreendido.

O post de hoje tem relação com algumas opiniões pessoais sobre coisas que eu gostaria que fossem diferentes em Python. Evidentemente que considero o GvR muito mais competente para definir uma linguagem de programação do que o Osvaldo Santana Neto (eu). E se algum dia eu tivesse competência tão grande e fosse criar a minha “linguagem de programação ideal” ao final do trabalho eu teria algo muito parecido com Python (ou Boo).

Existem também aquelas características ‘polêmicas’ em Python que a tornam tão especial.

Indentação (ou endentação? (ou identação? (ou edentação?)))

Essa é uma das características polêmicas de Python. Adicionar função sintática à indentação em Python foi uma sacada de gênio do GvR. Os benefícios proporcionados por essa prática são fantásticos. Particularmente o que mais gosto é o de que você fica ‘desestimulado’ a construir blocos de códigos muito longos porque com eles você se ‘perderia’ no código facilmente, já que é comum um editor de textos não exibir mais do que 50 linhas de textos na tela.

Mas com o bônus vem o ônus: configure seu editor de textos para trabalhar com identação com “<tab>” e abra um código de terceiro cuja indentação é feita com “espaços” e dê manutenção nesse código. Você vai tomar uma semana de “Syntax error” na tela.

Não gosto de linguagens que acrescente dependências de ferramentas externas para se extrair todo o seu potencial. Por sorte até os mais antigos editores de textos costumam permitir uma boa configuração de “Tabs / Espaços / Indentação”.

Esse é o ônus da função sintática da indentação em Python. Mas na minha linguagem eu pagaria esse preço sem pensar 2 vezes.

self…

Qual programador OO que nunca torceu o nariz quando teve que declarar o “self” na definição do método? Eu torci (pra falar a verdade ainda torço… sou péssimo digitador e vivo escrevendo “selg” no lugar).

A inclusão do self na definição de um método foi uma ‘decisão de projeto’ do GvR(?). Assim como outras decisões em outros projetos no mundo nem todas elas possuem fundamentos fortes e sólidos. O parâmetro “self” existe “porque sim”.

Alguns afirmam que é por causa do “The Zen of Python” (tente “import this” no prompt do Python) que diz em um de seus ‘versos’: “Explicit is better than implicit” (Explícito é melhor que implícito). Dessa forma dizer explicitamente que ‘self’ vem por parâmetro seria algo justificável.

Eu acho esse argumento questionável. Mas ele existe.

Se eu fosse dono da minha linguagem ela não receberia “self” como parâmetro do método. Mas receber “self” como parâmetro também não torna uma linguagem de programação ruim.

Em Boo o “self” não é necessário.

Tipagem Dinâmica

Prestem atenção quando falarem sobre a tipagem de Python para que não surjam equívocos. Python é uma linguagem de “tipagem forte e dinâmica” (oposto de fraca e estática).

Minha linguagem de programação seria exatamente igual à Python hoje. E ainda não tenho opinião formada sobre as idéias de tipagem opcional que estão circulando por aí com as discussões para o Python3000 que é algo diferente dos conceitos de tipagem por inferência existentes em Boo.

Mas devo admitir que tenho simpatia por conceitos como o Duck Typing, as Interfaces e os Protocols.

@decorators

Não gostei dessa sintaxe logo de cara. Fiquei horrorizado com essa “@” aí. Não gosto de linguagens que usem muitos símbolos (hint: Perl). Pra mim, quanto mais próximo à linguagem humana o código se parecer melhor.

Não gostei dessa sintaxe, mas ao usá-la eu fui obrigado à admitir que ela é superprática e meu voto que antes era “-1″ foi para “0″ para a sintaxe (sim, porque o conceito de decorator é legal e já existia na linguagem).

A minha sintaxe favorita era a:

def foo(bla) [dec1, dec2]:
   ...

mas ela não foi escolhida porque em casos (quase que inexistentes) de muitos decoradores na definição da função o código ficava muito poluído.

Em Boo a sintaxe escolhida foi:

[dec1, dec2]
def foo(bla):
  ...

Que também é boa mas é incompatível com uma construção Python válida como esta (Bamboo, se eu estiver errado me corrija):

[funcao_falsa, funcao_verdadeira][a==1]()

… e por esta razão ela não foi considerada.

Módulos e nomenclatura

Em uma conversa com o Luciano Ramalho ele me disse que os nomes de funções builtin, módulos e classes em Python deveriam seguir um padrão para facilitar o ensino e para facilitar a vida de pessoas que não tem memória para ficar armazenando nomes estranhos (como eu).

Eu concordo com ele principalmente se levarmos em consideração os módulos da biblioteca padrão do Python nas quais umas usam atributos com “nomesassim” e outras usam “nomesAssim” (existem também aquelas que usam “nomes_assim”).

Se não fosse o prompt interativo de Python com seu ‘autocompletion’ a vida de um desenvolvedor Python seria muito difícil por essa razão.

Portanto, em minha linguagem os nomes de métodos, módulos e classes da biblioteca padrão seguiriam normas ‘rígidas’ de nomenclatura.

Conclusão

Acho que vocês conseguiram ver que Python não é perfeita. Aliás, nunca deve dizer isso. Python é apenas uma excelente linguagem de programação (assim como Boo também é) e como tal merece ser divulgada e o seu uso também deve ser estimulado para que mais pessoas lutem para que ela melhore e, quem sabe um dia, essa tal de ‘perfeição’ não chega?