Pythonologia, o blog da Triveos » python

Interface Admin do Django: um baita quebra-galho.

Osvaldo Santana Neto — Sat, 03 Jul 2010 00:57:42 +0000

Já faz algum tempo que nós aqui na Triveos estamos usando Django e Python. Também tenho apresentado palestras e ministrado cursos de Django em vários lugares. Temos até mesmo um curso online de Python e Django à venda em um site desenvolvido em Django.

A Interface Admin do Django

Todos os programadores Django adoram falar sobre um dos grandes diferenciais desse framework: A Interface Admin.

Realmente, só quem desenvolve aplicações Web a bastante tempo e perdeu tempo precioso fazendo “telinhas de cadastro” sabe como essa tarefa é chata e pouco desafiadora. E todos que desenvolvem com Django agradecem a existência dessa funcionalidade.

A interface Admin do Django é prática, fácil de ser usada, e bonitinha. Uma mão na roda. Um baita quebra-galho. Até mesmo… mágica! A diferença entre um projeto entregue e um projeto atrasado.

Mas isso termina por aqui.

A interface de Admin do Django tem uma função clara: administrar o sistema. Tanto que ela foi feita para ser acessada só por usuários do “staff“.

Ela foi feita para que os desenvolvedores do site não percam tempo fazendo cadastros “bobinhos” que precisam ser mantidos só pelos funcionários da empresa.

O Django nasceu no mercado editorial e o primeiro projeto desenvolvido nele foi um gerenciador de conteúdo (CMS). A interface de Admin do Django servia (serve?) para que os editores, jornalistas, autores, etc. inserissem conteúdo nos sites dos jornais do grupo The World Company.

A interface Admin não foi feita para você desenvolver toda a sua aplicação nela. Ela é muito poderosa e até faz algumas coisas além de permitir somente a inclusão, visualização, alteração, e exclusão de conteúdo. Ela permite ordenar registros, efetuar buscas, definir ações, etc. Mas paramos por aí.

Funcionalidades mais elaboradas ou que precisam ser acessadas por pessoas que não fazem parte do “staff” continuam tendo o seu desenvolvimento necessário.

No site Ludeos, que foi desenvolvido em Django, a interface Admin ainda é usada para verificar os pagamentos dos cursos, e na manutenção das lojas e produtos. O fato do Django oferecer essa funcionalidade pra gente fez a diferença entre um projeto “atrasado” e um projeto “no ar”.

Mas o uso da interface Admin é um fator limitante para o nosso uso do sistema. Fica claro que, para que o projeto evolua, será necessário tirar algumas dessas funcionalidades da interface de Admin.

Em resumo: usem a interface Admin, mas saibam que em determinado momento ela pode limitar as suas ações e, nestes casos, Django oferece outras alternativas pra te ajudar a deixar a interface Admin: Generic Views. Falaremos sobre elas em outra oportunidade.

Django-ZODB 0.2rc1 lançado

Osvaldo Santana Neto — Tue, 08 Jun 2010 21:05:32 +0000

Post rápido pra anunciar que hoje eu subi o módulo django-zodb-0.2rc1 no PyPI. Publiquei essa versão para que outros pythonistas que usam Django e/ou ZODB possam colaborar com o projeto.

A ajuda que preciso com maior urgência é para corrigir os meus erros de inglês na documentação (deve ter toneladas deles no README.rst) e completá-la (removendo os XXX). Consertando os bugs que forem aparecendo e finalizando a documentação eu já lanço a versão 0.2final. Modificações que mudem a API só entram nessa versão se forem pra corrigir erros de design.

Novas funcionalidades podem ser incorporadas em um branch separado. O projeto está hospedado no github, portanto, isso é fácil de se fazer. Tem uma mini-lista de coisas que ainda faltam ser feitas no fim do arquivo README.

Layout provisório do site do projeto Django-ZODB

Já tenho um template pronto para o site do projeto mas não poderei trabalhar nisso nos próximos dias. Se alguém quiser mexer nisso é só falar comigo.

Trabalhando com Python e Django à moda Osvaldo

Osvaldo Santana Neto — Mon, 26 Apr 2010 01:45:40 +0000

Esse post está aqui para ser usado por mim como referência futura mas, como pode ser útil para outras pessoas vou deixá-lo público aqui no blog.

Software

Trabalhei muito tempo com Linux (e alguns outros Unices) e de três anos pra cá sou mais um Apple Fanboy que usa o excelente OS X. Mas acho que boa parte das dicas aqui ainda são úteis para usuários de Linux.

Terminal.app – Porque Mac é máquina pra ‘macho’ :D
bash – Pesadão, bloat, mas não consegui me habituar com outro. É o default do OS X.
Vim – Esse é o editor pra tudo. É difícil de aprender a usar mas é um F1. Depois que aprendemos a lidar com ele a gente voa. Uso a versão texto que acompanha o OS X.
TextMate – Esse eu uso para o desenvolvimento ‘pesado’. Dá pra usar o Vim pra isso também. Mas dependendo do meu humor eu escolho o TextMate para algumas coisas.
Rudix – O OS X não vem com tudo mas você encontra o que falta no Rudix.
Git – Uso o git pros meus projetos mas também tenho o Mercurial, Bazaar, Subversion, … instalados para contribuir com outros projetos open-source
virtualenv – ter um ambiente isolado para cada projeto Python onde você trabalha é muito legal. Já escrevi sobre o virtualenv aqui.
pylint e pyflakes – Analisadores estáticos de código.

Diretórios básicos

$HOME/
- Work – Diretório onde os projetos em que trabalho ficam.
- bin – Diretório com scripts, binários estáticos, etc. Esse diretório fica no $PATH

Configuração

Sempre que eu falar sobre um arquivo de configuração específico você pode encontrá-lo no endereço: http://github.com/osantana/personal.

Os arquivos ‘.’ (ponto)

.profile

Configurar 3 aliases: mv='mv -i' e cp='cp -i' pra evitar acidentes com arquivos sendo sobrescritos e ls='ls -G' para habilitar cores no comando ls.
Configurações genéricas para cores no terminal
Definir o vim como EDITOR padrão.
Definir LANG e LC_CTYPE como en_US.UTF-8 para que o Mercurial e alguns outros softwares funcionem corretamente.
Adicionar o diretório $HOME/bin ao $PATH. Nesse diretório eu jogo todos aqueles programinhas utilitários usados no dia a dia.
Configurações Python:
- export PYTHONSTARTUP="$HOME/.pystartup.py"
- source ~/bin/django_bash_completion
Configuração Java: export JAVA_HOME="/Library/Java/Home"
Configuração Ruby: adicionar $HOME/.gem/ruby/1.8/bin ao $PATH

Eu uso virtualenv em todos os meus projetos então crio duas funções para ativar os ambientes e entrar nos diretórios desses projetos:

# Uso: p nome_do_projeto
p() {
    cd ~/Work/$1*
    [ -f bin/activate ] && source bin/activate
}
 
# Uso: c
c() {
    [ -d "$VIRTUAL_ENV" ] && cd $VIRTUAL_ENV
}

.gitconfig

[user]
	name = Osvaldo Santana
	email = osantana na triveos.com
[color]
	status = auto
	diff = auto
	branch = auto
	ui = auto
	grep = auto
[alias]
	st = status
	ci = commit
	co = checkout
[merge]
	tool = opendiff
[core]
	legacyheaders = false
	excludesfile = /Users/osantana/.gitignore
    whitespace = trailing-space,space-before-tab
[apply]
    whitespace = fix
[repack]
	usedeltabaseoffset = true
[git-tmbundle]
	gitx-path = /Application/GitX.app/
[mergetool "opendiff"]
	cmd = opendiff
	trustExitCode = true
[clean]
	requireForce = false

.gitignore

.DS_Store
*.py[co]
*.tmproj
*~
*.swp*

.inputrc

Eu uso o modo vi também no console. Neste arquivo fica essa configuração e mais umas outras que deixam o comportamento do prompt do Mac mais parecido com o do Linux.

Já falei sobre essas configurações aqui no blog. Use por conta e risco.

.pylintrc

As configurações que eu uso para análise estática do código que eu produzo. Eu rodo o pylint antes de fazer o commit do meu código. Durante o desenvolvimento eu uso somente o pyflakes que é mais simples e rápido mas faz uma análise mais superficial do código. Eu costumava usar o pep8.py mas já faz um tempo que o aposentei.

.pystartup.py

Script executado pelo interpretador Python ao entrar no modo interativo. Eu configuro o ‘auto-completion’ do prompt interativo do Python, gravo o histórico de comandos, etc.

Infelizmente ele não funciona com o Python padrão do Mac porque o mesmo não é compilado com a biblioteca readline. Mas no Linux ele (deve) funcionar certinho.

.vimrc

Esse é o meu famoso arquivo .vimrc. Ele não tem nada de muito especial.

Outros arquivos

Existem outros arquivos mas, nestes casos, eles contém informações privativas e não faria sentido colocar aqui pra vocês :)

Criando e Usando um projeto Python (com Django)

Para exemplificar vamos criar um projeto “pythonologia”:

~ $ cd ~/Work
Work $ virtualenv --no-site-package pythonologia
New python executable in pythonologia/bin/python
Installing setuptools............done.
Work $ p pythonologia
(pythonologia) pythonologia $ easy_install django
(pythonologia) pythonologia $ django-admin.py pythonologia
(pythonologia) pythonologia $ cd pythonologia
(pythonologia) pythonologia $ git init
(pythonologia) pythonologia $ git add *.py
(pythonologia) pythonologia $ git commit -m "Initial commit"

Projeto criado e a estrutura de diretórios vai ficar mais ou menos assim:

~/Work/pythonologia
       |____ pythonologia
       |     |____ app_django1
       |      \___ app_django2
       |____ bin
       |____ include
        \___ lib
             \____ python2.6
                   |____ distutils
                    \____ site-packages

Os arquivos que não são mantidos no repositório Git ficam no diretório ~/Work/pythonologia ou em um diretório ~/Work/pythonologia/files. O arquivo de projeto do Textmate, por exemplo, fica em ~/Work/pythonologia/pythonologia.tmproj.

Eu também crio um link simbólico ~/Work/pythonologia/django -> ~/Work/pythonologia/lib/pythonX.X/site-package/Django-1.1.1-py2.6.egg/django para dar uma ‘espiada’ no código do Django quando necessário.

Quando eu quero trabalhar num outro projeto eu faço:

(pythonologia) pythonologia $ deactivate
pythonologia $ p outro_projeto
(outro_projeto) outro_projeto $

Eu estou num diretório qualquer e quero voltar para o diretório raiz do projeto basta fazer:

(pythonologia) ~ $ c
(pythonologia) pythonologia $

Python ainda é pythônico?

Osvaldo Santana Neto — Sun, 11 Apr 2010 01:04:46 +0000

Eu estava lendo um (longo) artigo que fala sobre várias coisas sobre como desenvolvíamos software no passado e como desenvolvemos hoje, etc… E num determinado momento ele fala sobre bibliotecas, frameworks e sobre um conceito denominado por ele “radius of comprehension“.

O conceito de “radius of comprehension” é simples: dado um determinado trecho pequeno de código, quanto de código a mais você precisa ler para entender o que ele faz. Quanto menor o “radius of comprehension” melhor.

Ao ler isso eu me lembrei de uma palestra do Luciano Ramalho onde ele fala que gosta da linguagem Python (e da idéia de algo ser ‘pythonico’) porque ela “cabe na cabeça” dele e acho que isso tem uma relação direta com a idéia de “radius of comprehension“.

Eu também pensava da mesma forma que o Luciano. Achava que Python “cabia” na minha cabeça. Mas hoje eu devo admitir que isso é parcialmente verdade.

Em primeiro lugar eu acho que a linguagem vem crescendo demais desde a versão 2.2. Adicionando funcionalidades e “acúcares sintáticos” cujos benefícios podem ser facilmente questionados.

Mas não vou falar muito da linguagem não. Vou falar de alguns módulos da biblioteca padrão do Python que são praticamente impossíveis de serem usadas sem ter a documentação à mão:

logging – esse é o pior de todos. Não tem uma única vez que eu não preciso recorrer à documentação do módulo pra fazer algo “bobo”. Sei que um “logging.log(…)” basta para o básico, mas se você precisa de algo básico+1 você já se vê obrigado a ler toda a documentação do módulo. Acho que o problema desse módulo foi tentar copiar o log4j do mundo Java. Todos nós conhecemos o gosto por “over engineering” dos programadores Java.
ConfigParser – não tenho muito a dizer. Porque esse módulo precisa daqueles conceitos complicados de configurações “globais”, busca de arquivos em múltiplos diretórios, etc. Ele poderia implementar o simples e fácil e deixar as extensões para bibliotecas de terceiros.
email – precisei usar esse aqui uma única vez e desde então eu tremo de medo sempre que alguém me pede pra “manipular e-mails” em uma aplicação Python. Sei que manipular e-mails é complicado se considerarmos a quantidade de “variações dos padrões” existentes num serviço que tem quase a idade da Internet, mas as abstrações devem ser construídas para nos poupar desses detalhes, não?
xml.dom e xml.sax – eu já não gosto de XML, imagina manipular XML com essas duas bibliotecas “podres”. Se eu pego um código pra dar manutenção e esse código usa uma dessas duas bibliotecas eu triplico o valor do serviço.
re – neste caso eu não acho que seja muito culpa do Python, mas peça pra alguém que conheça regex mas não conheça Python explicar a diferença entre re.search() e re.match(). Ou mostre pra ele uma regex com “(?P.*)” significa.

Além dessas tem outras que não vou me lembrar. Tem também algumas bibliotecas, módulos e frameworks no atual “eco sistema” do Python que simplesmente não entram na minha cabeça:

Zope e Plone – a turma do PythonBrasil já conhece essa história. Eu tentei bem umas 3 vezes estudar essa dupla e nas 3 eu não consegui ir além de abrir a interface de administração do Zope. Mas de duas uma: ou sou burro demais ou o troço é desnecessariamente complicado. Por sorte o ZODB funciona separadamente porque esse sim é poderoso e fácil de usar.
Buildout – esse eu já usei basicamente pra instalar alguns programas mas é uma caixa preta completa pra mim. Não tenho certeza, mas acho que ele nasceu no (ou em função do) Zope/Plone e talvez isso explique um pouco disso. Eu não sei direito se ele é um sistema de build, um sistema pra criação de ambiente de desenvolvimento, ou se é algum sistema alienígena de IA.

Eu sei que os problemas que temos que resolver hoje em dia são bem mais complexos do que os que tínhamos que resolver quando comecei a programar, mas problemas complexos não precisam de soluções que deixem transparecer essa complexidade.

Textmate “Django test executator tabajara”

Osvaldo Santana Neto — Mon, 29 Mar 2010 19:22:32 +0000

O script a seguir pode ser usado para executar testes automatizados em uma aplicação Django a partir do Textmate.

Ele deve ser usado como um “command” no bundle “Python Django” do Textmate e funciona exclusivamente com o sistema de testes do próprio Django (manage.py test).

#!/bin/bash
 
python=$(/usr/bin/which ${TM_PYTHON:-python})
project="$(dirname "$TM_DIRECTORY")"
app="$(basename "$TM_DIRECTORY")"
 
# virtualenv
if [ -x "$project/../bin/python" ]; then
   python="$project/../bin/python"
fi
 
class_filter="s/^ *class +([A-Za-z0-9_]+Test)\(.*Test.*\):/\1/p"
test_filter="s/^ *def +(test[a-zA-Z0-9_]+) *\(self.*$/\1/p"
 
echo ""
echo "Django test results"
echo ""
echo "Django test results
"
if [ -f "${project}/settings.py" -a \
     -f "${project}/manage.py" ]; then
  echo "Test Results for: $app
"
  echo ""
 
  # selected text test
  tests=$(
    if [ x"$TM_FILENAME" = x"tests.py" -a \
         "$TM_SELECTED_TEXT" ]; then
      classname=$(
        sed -nE "1,${TM_INPUT_START_LINE}p" "${TM_FILEPATH}" |\
        sed -nE "$class_filter" |\
        tail -1
      )
      echo "$TM_SELECTED_TEXT" | while read l; do
        class_parse=$(echo "$l" | sed -nE "$class_filter")
        [ "$class_parse" ] && classname="$class_parse"
        test_parse=$(echo "$l" | sed -nE "$test_filter")
        [ "$test_parse" ] && echo "$app.$classname.$test_parse"
      done
    fi
  )
 
  [ -z "$tests" ] && tests="$app"
  $python $project/manage.py test $tests
  # I don't have time to "fight" against wordpress
  # echo "CLOSE_pre_tag"
else
  echo "\"color:red;\">Error: Django App expected.
"
fi
# Again, I don't have time to "fight" against wordpress
# echo "CLOSE_body_tag CLOSE_html_tag""

Este comando requer que o Bundle “Python Django” esteja instalado. Existe uma versão no repositório do próprio Textmate e uma versão atualizada no bitbucket.
Acione “Bundles->Bundle Editor->Show Bundle Editor”.
Selecione “Python Django” e clique no botão “+ New Command”.
Escolha um nome para o comando. Aqui eu uso “Run App Tests”.
Configure as opções do comando conforme abaixo:
- Save: All files in Project
- Commands: O script acima
- Input: None
- Output: Show as HTML
- Activation: Key Equivalent ⌃⌥⌘R
- Scope Selector: source.python.django

Modo de usar

O comando é acionado com as teclas ⌃⌥⌘R.
O comando executa apenas os testes da aplicação à qual o arquivo que você está editando pertence.
Por padrão o comando executará todos os testes da aplicação.
Se você selecionar o os testes que você quer executar no arquivo django_app/tests.py o comando executará apenas esses testes.
O comando tem um suporte básico para usuários do virtualenv. Para que o comando use o virtualenv é necessário estruturar os seus diretórios da seguinte maneira: virtualenv_root/django_project/django_app. Isso é necessário para que o comando encontre o interpretador virtualenv_root/bin/python.

Treinamento Python e Django

Osvaldo Santana Neto — Wed, 02 Dec 2009 14:13:36 +0000

Atualização Importante:

A Triveos está lançando o seu treinamento de Desenvolvimento Web Ágil com Python e Django e por isso pega carona nesse conceituado blog (que por coincidência é um dos sócios da Triveos) para anunciar este lançamento.

Eu não costumo fazer esse tipo de post (jabá) por aqui mas este é um caso especial por dois motivos: o produto anunciado foi criado pela minha empresa (como eu já havia dito); e porque que até o momento são poucas as empresas que ministram esse curso no Brasil.

Esse treinamento é o primeiro entre muitos que planejamos desenvolver no próximo ano sempre com algumas características:

treinamentos in-company — isso nos dá mobilidade e permite que o treinamento seja ministrado em qualquer lugar do Brasil e não somente no eixo Rio-São Paulo.
treinamentos de curta duração — achamos que tecnologias precisam ser simples e que se elas forem realmente simples não seria necessário investir meses num treinamento. O treinamento de Python e Django precisa de 5 dias apenas para ser ministrado com grande tranquilidade para pessoas que já desenvolvem em alguma linguagem OO.
treinamentos personalizáveis — a linha principal do treinamento é mantida mas algumas modificações podem ser feitas para adequar o treinamento aos requisitos das empresas. Exemplos: dedicar um tempo do treinamento à implantação do Django, apresentar alguma biblioteca Javascript para desenvolvimento de RIAs, ministrar só o módulo Django, etc.
materiais de qualidade — nada de apostilas contendo só slides impressos. Disponibilização de todo o material usado em aula (Slides, repositório de códigos, etc).
instrutores qualificados — não posso falar muito mais sobre isso. Sou um dos instrutores :D

Quem tiver interesse no treinamento pode entrar em contato com a gente através do site ou diretamente comigo.

Update: Pessoal, não tinha ficado claro mas, a Triveos só trabalha com treinamentos in-company, ou seja, não temos infra-estrutura para ministrar esse treinamento em nossa empresa. Fazemos isso dentro da sua empresa (ou da empresa onde você trabalha). De qualquer maneira estamos avaliando um modo de atender às demandas que estão surgindo.

PythonBrasil [5]

Osvaldo Santana Neto — Wed, 22 Jul 2009 17:50:24 +0000

Os preparativos para a 5ª edição do encontro brasileiro da comunidade Python já estão a todo vapor (o evento era conhecido anteriormente como PyConBrasil).

A PythonBrasil[5] acontecerá em Caxias do Sul – RS nos dias 10, 11 e 12 de setembro no campus da Universidade de Caxias do Sul (UCS).

As inscrições já estão abertas e é possível adquirí-los com o desconto máximo até o dia 07 de agosto. Depois disso os valores vão aumentando. Estudante, membros da Associação Python Brasil, da Abraweb e da SBC contam ainda com descontos.

Além das inscrições a Chamada para Trabalhos também estará aberta até o dia 26 de Julho (domingo agora! Não perca tempo!) para palestras e treinamentos.

Eu, como não podia deixar de ser, participei de todas as edições da conferência e posso dizer: é fantástico. O encontro com os amigos, as palestras surpreendentes e a interação com o público (que é fácil por conta do tamanho do evento) fazem esse evento único.

Gostaria de pedir pros leitores do meu blog que ajudem na divulgação do mesmo. Vocês encontrarão o material para isso no próprio site.

Dicas para um bom programa em Python

Osvaldo Santana Neto — Tue, 03 Mar 2009 18:09:27 +0000

Oi pessoal, desta vez eu vou pular as ‘desculpas’ por ter demorado tanto para postar aqui no blog e vamos direto ao assunto.

Recentemente eu tenho trabalhado bastante com Python (dã!) desenvolvendo projetos de diversos tipos e resolvi escrever aqui sobre algumas coisas que pratico enquanto desenvolvo.

Código mais robusto

Deu certo ou errado?

O que você faz quando acontece algo errado na execução do seu método? O que você responde à requisição que lhe foi feita?

Eu tenho visto em muito código por aí os desenvolvedores retornando valores sentinela (None, null, 0, -1, etc.) para avisar que algo incorreto aconteceu na execução do método.

def f(arg):
   if not arg:
      return None
   return [ "resultado", "de", "um", "processamento"  ]

Algumas linguagens de programação não possuem estruturas de tratamento de exceção e, neste caso, o uso de sentinelas é válido. Mas quando a linguagem de programação te disponibiliza essa funcionalidade é bom usá-la.

def f(arg):
   if not arg:
      raise ValueError("Argumento Invalido")
   return [ "resultado", "de", "um", "processamento"  ]

Deixem as exceções fluirem.

Isso mesmo. A menos que você saiba exatamente o que você deve fazer quando uma exceção aparece deixe-a exceção “subir”. Pode ser que “lá em cima” alguém saiba cuidar dela adequadamente.

Quando não fazemos isso estamos ocultando informação importante para os usuários do nosso código (sejam eles usuários, outros desenvolvedores ou nós mesmos).

def f():
   try:
      return conecta()
   except ExcecaoQueDeveriaSerErro:
      return None

Quando eu implemento esse tipo de método/função eu faço assim (na verdade eu não implementaria f() e chamaria conecta()):

def f():
   return conecta()

O que seu método/função retorna?

Código que eu encontrei recentemente:

def get_fulanos():
   q = Q("select * from patuleia where alcunha like 'fulano%'")
   ret = [ str(fulano['nome']) for fulano in q ]
   if len(ret) == 1:
      return ret[0]
   return ret

Perceberam o que está errado? O seu método retorna uma lista de Fulanos ou retorna Fulano?

Isso está conceitualmente errado e pode fazer você perder horas preciosas do seu dia tentando achar um bug causado por esse tipo de código.

Aconteceu comigo. Note que str() implementa uma interface de sequence da mesma forma que list(). Então o erro passa silenciosamente no caso abaixo:

old_fulanos = [ "Ze Ruela", "Ze Mane" ]
old_fulanos.extend(get_fulanos())
print old_fulanos

Rodando esse código você vai obter ['Ze Ruela', 'Ze Mane', 'q', 'u', 'a', 'c', 'k'] sendo que, em mais de 90% dos casos, o que você gostaria de ter seria: ['Ze Ruela', 'Ze Mane', 'quack'].

“Nada” é diferente de “alguma coisa”.

Essa dica é só uma complementação da primeira e da segunda dica.

Quando o seu método/função retorna uma collection (seqüência, conjunto, hash, etc) vazia você deve retorná-la vazia e não um valor sentinela (como None). Isso facilita a vida de quem vai usar o seu método/função:

def vazio():
   return []
 
for elemento in vazio():
   pass #... faz algo se o conjunto contiver dados ...

Se você retorna um valor sentinela:

def vazio():
   return None
 
elementos = vazio()
if elementos:
   for elemento in elementos:
      pass # ...

Notou que tivemos que criar uma variável com o resultado da operação (para não precisar chamá-la duas vezes) e tratar a sentinela com um “if“? Se eu esqueço de tratar a sentinela meu programa vai quebrar.

Lembre-se sempre que uma collection vazia tem valor booleano “False“.

Todo ‘elif‘ tem um irmão ‘else‘.

Sempre que você precisar usar uma construção if/elif coloque uma cláusula ‘else‘.

Além de usar a cláusula ‘else‘ eu geralmente faço com que ela gere uma exceção. Desta forma eu sou obrigado a trabalhar todas as possibilidades nos ‘if/elif‘ evitando ocultar uma situação que pode ser inválida.

class InvalidCommand(Exception):
   pass
 
def minihelp(comando):
   if comando == "print":
      return u"""Imprime dados na tela.
                 Deixará de ser comando no Python 3.0"""
   elif comando == "assert":
      return u"""Certifica se uma condição é
               verdadeira e gera uma excessão em caso contrário"""
   elif comando == "...":
      pass # ...
   else:
      raise InvalidCommand(u"Comando %s inválido." % (comando,))

Eu gosto dessa prática mas isso não significa que você deva seguí-la sempre. Existem situações onde ter um “valor default” é necessário e nestes casos o uso do else sem levantar exceção se faz necessário.

if comando == "if":
   print "Vai usar elif?"
elif comando == "elif":
   print "Muito bem. Agora falta o else"
else:
   print "Pronto. Agora está bom."

“Pythonismos”

Use mais atributos públicos do que atributos protegidos (“_“).

Programadores acostumados com Java utilizam muito as cláusulas ‘private‘ e ‘protected‘ para encapsular os atributos de um objeto para logo depois implementarem os getters e setters para acessar esses atributos.

Essa prática é aconselhada em Java porque em algum momento do futuro você, talvez, precise validar esses dados ou retornar valores calculados. Nestes casos os programadores apenas implementam essa lógica nos métodos que acessam o atributo privado.

Mas em Python isso não é necessário. Em Python você pode transformar seu atributo público em uma “property” que não muda a forma de se acessar o atributo e permite o acrescimo de lógica ao acesso do mesmo.

Evite usar “__“.

Por convenção, em Python, todo método ou atributo iniciado com um “_” é considerado privado (equivalente ao protected em Java) e não deve ser acessado de fora da classe mesmo sendo possível fazê-lo.

Dito isso parece meio óbvio que não precisamos usar “__” para dificultar ainda mais o acesso à esse atributo/método. Além disso o uso do “__” traz alguns incoveninentes para quem quer derivar a sua classe e acessar este método/atributo já que o Python o renomeia acrescentando o nome da classe ao seu nome (__attr vira _Classe__attr).

Não sobrescreva builtins.

Python disponibiliza várias funções e classes builtins que facilitam muito o uso da linguagem e economizam digitação. Mas esses builtins tem nomes muito “comuns” e frequentemente a gente usa os nomes dos builtins como nomes de identificadores. Eu mesmo vivo (vivia) fazendo isso.

O problema é que em certos momentos alguns problemas podem acontecer quando você tenta chamar um buitin que já não é mais um builtin. Na maioria das vezes o problema “explode” logo e você rapidamente conserta mas em alguns casos você pode perder muitas horas tentando achá-lo.

Algumas pessoas usam um “_” no fim do nome do identificador (ex. “id” vira “id_”) mas eu acho isso um pouco feio então uso só quando não encontro uma alternativa melhor.

Vou colocar aqui uma tabela de equivalências que eu costumo usar para substituir o nome dos builtins mais comumente sobrescritos:

id – ident, key
type – kind, format
object – obj
list – plural (lista de element vira elements)
file – fd, file_handler
dict – dic, hashmap
str – text, msg

Análise estática economiza seu tempo.

Eu uso o pylint, mas conheço algumas pessoas que preferem o pyflakes ou o PyChecker.

A dica é essa: usar um programinha de análise estática como esses pode diminuir consideravelmente aqueles errinhos chatos de sintaxe, ou de digitação. Pode limpar os ‘import’ desnecessários do seu software, etc, etc.

É lógico que esse tipo de ferramenta não substitui uma boa política de testes mas é um bom complemento para ela.

Challenge yourself

Máximo de 3 níveis de indentação. (ou 4 se estiver dentro de uma classe)

Ao se esforçar para que seu código não fique muito aninhado você está trabalhando melhor a implementação dos seus métodos e funções. Nem sempre é possível (ou aconselhável) restringir tanto o nível de identação do seu código mas muitas vezes isso melhora a sua implementação.

Máximo de 2 indireções.

Recebeu um objeto como parâmetro? Chame apenas métodos dele e evite ao máximo chamar métodos do retorno desses objetos:

def f(obj):
    obj.metodo() # legal!
    obj.metodo().outro_metodo() # ruim!

Quando você chama um método pra um objeto retornado por outro método você está aumentando o acoplamento entre as classes envolvidas impedindo que uma delas seja substituída (ou reimplementada) ‘impunemente’.

Essa regrinha é uma das regrinhas da Lei de Demeter.

Máximo de 0 ‘if/elif/else‘s.

Polimorfismo é isso. No mundo OO ideal, perfeito e utópico praticamente não precisaríamos do comando “if” e usaríamos somente polimorfismo. Mas… como não conseguimos isso tão facilmente^* devemos, ao menos, usar o “if” com moderação.

Conclusão

Esta é uma lista incompleta de dicas para programadores Python. Se futuramente eu lembrar ou aprender algo novo eu volto aqui para falar sobre o assunto.

Alguns desenvolvedores podem não concordar com as dicas. Neste caso eles podem enriquecer ainda mais esse texto argumentando sobre o as suas restrições no espaço para comentários.

Se você tiver alguma dica para compartilhar com a gente coloque nos comentários. Se ela for boa mesmo eu coloco ela no corpo principal do blog.

^* eu mesmo só consegui fazer uma aplicação OO funcional sem usar um único if. Era uma implementação do joguinho de adivinhação de animais (aquele que pergunta “Vive na água? (s/n)”) em Smalltalk.

Update: pequena correção sugerida pelo Francisco nos comentários: s/Classe/_Classe/.

PyConBrasil 2009 na sua cidade. O prazo está acabando!

Osvaldo Santana Neto — Tue, 04 Nov 2008 03:06:18 +0000

Dia 10 de novembro termina o prazo para envio das candidaturas à cidade-sede da PyConBrasil 2009!

Se você mora numa cidade com uma comunidade pythônica entusiasmada, com uma boa infra-estrutura para sediar o evento e gostaria de ver reunida a ‘nata’ do Python no Brasil (e no mundo) é a sua chance de candidatá-la para sediar a próxima edição do maior evento de Python da América Latina!

Para candidatar é fácil. Basta preencher um formulário e seguir as dicas do Manual do Big Kahuna que as suas chances aumentam.

Os critérios para escolha da cidade variam bastante entre os participantes da banca de avaliação mas parece haver um consenso de que passam por:

Participação, importância do Big Kahuna na comunidade e sua capacidade de coordenação
Força do GruPy local
Disposição de ambos para trabalhar duro durante quase um ano na organização do evento
“Potencial pythonico” da cidade (quantos desenvolvedores python conseguiremos ‘converter’)
Infra-estrutura pro evento
Infra-estrutura da cidade-sede (transporte, acesso aéreo/terrestre)
Mais alguns outros critérios que, com certeza, esqueci…

Os resultados serão divulgados no dia 25 de novembro. A banca de avaliação ainda não foi formada mas logo que tivermos mais detalhes eu aviso por aqui.

A Lição Final

Osvaldo Santana Neto — Wed, 24 Sep 2008 18:55:03 +0000

Dia desses eu estava trabalhando e ao olhar na barra do meu Google Talk eu vi que o Guido van Rossum (criador da linguagem Python) havia colocado o endereço de um vídeo no Youtube. Achei que era algum vídeo legal sobre Python e resolvi abrir.

Era o vídeo de uma palestra de um professor norte-americano que trabalhava na área de tecnologia de realidade virtual. Até aí nada de mais (eu sequer me interesso pelo assunto).

Continuei a assistir o vídeo por mais um tempo mais por “fé” na indicação do Guido do que por qualquer outra razão. Em certo momento do início da apresentação o professor, chamado Randy Paysch, mostra um Raio-X do fígado dele onde se conta 10 tumores e ele diz que tem entre 3 e 6 meses de vida.

Ele então começa a falar sobre sonhos e sobre como realizá-los. Sua habilidade como orador é invejável. Continuo assistindo a palestra. Me emociono.

Semanas depois leio na revista Época que esse vídeo havia se tornado uma febre no Youtube e que o professor Pausch estava preparando um livro com o conteúdo dessa mesma palestra juntamente com um amigo. Pensei (me esquecendo que o cara estava condenado à morte): pronto, mais um livro de auto-ajuda que vai deixar o autor rico.

A algumas semanas atrás fiquei sabendo que o professor faleceu e em uma de minhas passeadas em livrarias pude ver que uma tradução do livro já estava disponível no Brasil. Voltando do Rio de Janeiro, onde havia participado da PyConBrasil 2008, resolvi comprar o livro pra ler durante a viagem de volta.

A coincidência

Lendo o capítulo “24. O tolo que se redimiu”, onde o professor conta a história de um de seus alunos (chamado Tommy) que era fã de Guerra nas Estrelas e sonhava em trabalhar na produção dos filmes da saga, eu esbarro no seguinte trecho (página 135):

Não é coincidência? Eu conheço o cara através do criador do Python e voltando de uma conferência de Python eu leio que um dos alunos do cara realizou o sonho de trabalhar na Industrial Light & Magic porque conhecia Python.

O livro

No geral o livro é um complemento ao vídeo e foi escrito, segundo o autor, como uma forma de deixar uma mensagem para os seus filhos.

Seria um típico livro de auto-ajuda se não fosse a biografia de um professor que deixou uma mensagem muito bonita para sua família pouco antes de morrer. É um livro onde se encontra muitos “clichês”, muitos momentos piegas e que muitas vezes emociona o leitor (principalmente aqueles que já são pais).

Ele tem uma encadernação muito bonita com capa dura e um tamanho reduzido que o torna excelente para presentear os amigos. Por se tratar de um livro barato cuja leitura é muito rápida (li ele em 1 dia) eu recomendo a todos que tem seus sonhos e gostariam de realizá-los. Mais ainda àqueles que tem filhos.

Para comprar:

Submarino (mais barato no momento em que faço esse post)

Livraria Cultura

Lojas Americanas (dica do Prof. Marco André)

A Lição Final (apenas R$9,90!)