O documento discute como criar utilitários de linha de comando em Python de forma elegante. Ele cobre tópicos como códigos de retorno, parsing de argumentos, logging, controle de sinais, arquivos especiais, ferramentas de desenvolvimento, documentação e interfaces de usuário baseadas em texto. O documento enfatiza a importância de se ter uma licença amigável, documentação clara, testes automatizados, integração contínua e uma comunidade ativa para projetos Python de alta qualidade.
5. Critério Interno
• Projeto tem documentação clara e com exemplos
• Projeto tem um conjunto de testes automatizados
(unittests, nose, etc.)
• Projeto tem uma boa estrutura de diretórios e
arquivos
• Projeto tem um buildsystem (make, setup.py, etc.)
• Projeto instalável dentro de um Virtual Env
5
6. Critério Externo
• Projeto possui uma licença de uso amigável (BSD, MIT, GPL, etc.)
• Projeto está hospedado e possui uma homepage (GitHub, GitLab,
Bitbucket, etc.)
• Projeto possui documentação disponível on-line (readthedocs, github
pages, etc.)
• Projeto possui Integração Contínua (Jenkins, Travis, etc.)
• Projeto disponível no Python Package Index [https://pypi.python.org/pypi]
• Pacotes disponíveis no Debian, BSD Ports, Rudix, etc.
• Projeto possui uma comunidade ativa e amigável
6
9. Códigos de Retorno
(Exit codes)
• Muitos buildsystems (ex.: make) e sistemas de automação (ex.:
fabric) necessitam do código de retorno para saber se podem
continuar com a tarefa.
• 0 = OK, !0 = NOK
• 0 = programa rodou corretamente (EXIT_SUCCESS do C)
• 1 = houve um erro na execução (EXIT_FAILURE do C)
• 2.. = diferenciação de tipos de erros (não há um padrão)
• 64-67 = EX_* (/usr/include/sysexits.h)
• 128+n = saída com sinal n (143 = (128 + 15) SIGTERM)
9
10. Retorno em Python
(seu script deve retornar um)
• return 123 # dentro de __main__()
• sys.exit(123) # em qualquer lugar
• Caso contrário, assume um “retorna 0” OK
(realmente, OK?)
10
11. Parsing de Argumentos
• getopt (desde a antiguidade)
• optparse (py2.3-py.2.7)
• argparse (py2.7-)
11
15. Logging
• O módulo logging é odiado por não ser “Pythonico”
porém o formato de logging e customizações são
necessários em ambientes de produção
• Em cada módulo:
• log = logging.getLogger(__name__)
• log.error(“Can’t start: %s”, msg)
• log.info(), log.warn(), log.debug(), etc.
15
20. Ferramentas
• Python Debugger (pdb)
• import pdb ; pdb.set_trace()
• profiler
• virtualenv, tox (virtualenv-based automation of test activities)
• pylint, pychecker
• GitHub, Bitbucket, Travis, Jenkins, …
• Um ótimo editor: vim, emacs, textmate, notepad++, etc.
• Uma IDE: PyCharm, Eclipse, etc.
20
21. The Python Package Index
(PyPI)
• Central de repositórios de módulos para Python
• Módulo distutils
• Script setup.py
• https://wiki.python.org/moin/Distutils/Tutorial
21
24. Documentação
• Geralmente se escreve com Markdown ou
reStructuredText (RST)
• Markdown é mais simples de sintaxe e é um
formato bem popular
• RST é mais complexo, porém popular em
projetos Python
• Sphinx (Python Documentation Generator) [http://
sphinx-doc.org]
24
31. • Projeto tem uma licença amigável (BSD, MIT, GPL, etc.)
• Projeto tem uma interface coerente e amigável
• Projeto tem documentação clara e com exemplos
• Projeto tem um conjunto de testes, cobertura e IC
• Projeto disponível no PyPI
• Projeto possui uma homepage
• Projeto instalável dentro de um Virtual Env
• Projeto tem uma comunidade legal
• Projeto é mantido regularmente
Resumo
31
32. Fim
• Livro do Luciano Ramalho: “Fluent Python”
• Rudix! Ports e packages para o OSX
• rudix.org
• HIRE ME! Me contrate :)