Customizando o prompt interativo do python

Em algumas distros linux notei que o interpretador padrão do Python, aquele invocado pelo comando python no terminal, possuiam autocomplete e histórico. Eu sei que existe o ipython o bpython, mas em várias situações onde eles não estão disponíveis, o interpretador interativo padrão é a melhor solução.

Existe uma variavel de ambiente chamada PYTHONSTARTUP, que guarda o path do seu script de inicialização, por exemplo:

export PYTHONSTARTUP="~/.pythonstartup"

O conteúdo de ~/.pythonstartup pode ser customizando à vontade, e ainda existe uma documentação básica sobre o assunto aqui.

Um exemplo de pythonstartup :

import readline
import rlcompleter
import atexit
import os
from datetime import datetime as d

readline.parse_and_bind('tab: complete')

histfile = os.path.join(os.environ['HOME'], '.pythonhistory')

try:
    readline.read_history_file(histfile)
except IOError:
    pass

atexit.register(readline.write_history_file, histfile)

def isodate():
    return d.now().isoformat()

del os, histfile, readline, rlcompleter

Como você pode ver é possível adicionar funções e objetos personalizados para tornar seu prompt mais flexivel.

O dia em que o Glade parou, um passeio pelos RADs Opensource

A um ano atras fiz um projeto para o CCJ que envolvia a criação de um sistema de gerenciamento de telecentros, uma versão simplificada de um programa para gerenciar Lan-Houses chamdo Pylan.

O Pylan foi feito em python e gtk, e o primeiro protótipo funcional ficou pronto em 3 semanas, bem rápido, mas como não usei uma ferramenta de RAD para desenhar a interface posso assegurar que pelo menos metade do tempo de coding foi tentando ajustar a interface na mão, principalmente os formulários. Como o projeto tinha tudo para ser um oneshot, isso não era um problema tão grande, já que no futuro poucas mudanças na interface seriam necessárias.

Mas hoje eu vivo uma situação curiosa, apesar de ter minha empresa aberta legalizada e plenamente funcional, sou empregado em tempo integral em outra .A Hyddro foi concebida para ser uma empresa de verdade, e não uma passadora de notas, ela surgiu num vácuo de negociações que surgiu no processo da minha integração ao grupo da empresa em que sou empregado por circunstâncias obtusas, falhas de comunicação, desconfianças e conflito de interesses que são papo de bar, e não pra blog. Ou seja, toco minha empresa fora do horário comercial, e isso cansa, cansa muito e portanto surgiu a necessidade de usar RAD no produtos da empresa.

Surgiram clientes em potencial para uma versão atualizada do Pylan, que bancariam seu desenvolvimento por alguns meses, e um outro cliente que abriria a portas para um novo mercado, o das lan houses e cyber cafes com linux. Um mercado cheio de soluções pela metade, ruins ou emuladas via dosbox, mas que tem um potêncial muito grande se bem trabalhado.

Voltando, ferramentas de RAD permitem desenhar as interfaces dos programas de forma independente do código, tudo clicando e arrastando, depois é só escrever as classes e os métodos para se conecetar com a interface, reduzindo drásticamente o tempo de desenvolvimento, o que pra mim é fundamental já que não vou conseguit manter um emprego integral e tocar meu negócio sem isso…

No linux existem algumas ferramentas desse tipo:

  • Netbeans possui uma ferramenta de RAD integrada ao IDE, para java.
  • QTDesigner, cria arquivos .ui , que podem ser aproveitados por programas feitos em C++, python, ruby, java, C#  usando QT.
  • Glade, cria arquivos xml para biblioteca GTK, para liguagem C/C++, python, ruby, java etc…
  • wxGlade, cria código em python, c++, perl , lisp ou um xml que pode ser importado pela aplicação.
  • Mono, cria interfaces para qualquer liguagem integrada ao CLR/.NET, C#, IronPython, IronRuby etc…

Usei várias madrugadas para desenvolver protótipos em cada uma dessas soluções, considerando minhas necessidades:

  • Multiplataforma
  • Desempenho decente em Windows e Mac
  • Visualmente bem integrado com a plataforma que está rodando
  • Fácil de instalar, sem muitas dependências
  • Velocidade no desenvolvimento
  • Desenvolvimento Ágil

Mono


O primeiro protótipo que desenvolvi foi em Mono, e digo que foi a experiência mais fantástica em desenvolvimento desktop que já tive !

O monodevelop, não fica no seu caminho, ele é realmente útil, simples de usar e intuitivo, C# é bem parecido com Java, possui bibliotecas bem resolvidas e uma boa compatibilidade com bibliotecas livres desenvolvidas para .NET (sim isso existe).

É Super multiplataforma, rodou bem rápido no Linux, Windows e Mac, se integrou visualmente muito bem no Linux e no Windows… no Mac ficou bem estranho. O ubuntu já vem com mono instalado, no windows tive que instalar o GTK#, no mac tive que instalar o mono e o GTK#, mas em todos os casos foi bem tranquila as instações e o tempo de download das bibliotecas.

Existem bibliotecas como a NUnit para testes, e bons depuradores e profilers integrados no monodevelop.

Levei pouco mais que 4 horas para terminar o protótipo, simplesmente fantástico.

Mas o mono tem um problema sério, o projeto é constantemente trolado pela microsoft e pela comunidade opensource, só pra se ter uma idéia existem milhares de tutoriais e scripts para tornar sua distro mono-free. Tem até distro que seu único diferencial é não ter mono !

Netbeans

No netbeans tive uma experiência de produtividade parecida com a do Mono, com a vantagem de usar swing, não tive que instalar nada na hora do deploy, bastou apenas executar o Jar. O Swing integra nativamente o ‘look’ da aplicação, mas não o ‘feel’, o programa ficou estranho em todos os sistemas, e ficou lento … muito lento. Lendo a respeito, a galera diz que o swing não recebe atenção dos desenvolvedores do java a pelo menos 5 anos, deve ser verdade.

Por mais que eu tenha gostado o desempenho e a pobreza de widgets o tirou da jogada.

QTDesigner

A qualidade gráfica e a riqueza de widgets é fenomenal, outstanding, mas todo seu potencial só é atingido usando C++, eu queria muito usar python, não que não seja possível, mas tenho minhas dúvidas já que o pyQT é desenvolvido por uma empresa independente da nokia.

Outra coisa que pega é que o PyQT exige pagamento de licença no caso de softwares comerciais, o software é livre, mas vou receber pra melhora-lo, tenho muitas dúvidas.

WXGlade

Bem rápido de desenvolver, tem muitos widgets legais, é comparavel como  QT nesse ponto, a portabilidade é fantástica, basta instalar um pacotinho e o sistema funciona como se fosse nativo. É uma ótima opção, muito bem documentado, mas possui bugs e isso é um tanto preocupante.

Glade

Foi minha primeira opção, a ferramenta é muito boa, da pra integrar com o pygtk tranquilamente. O grande problema é que para rodar pygtk no windows é necessária a instalação de meia dúzia de pacotes, além do python claro, o que incha o sistema. No Mac roda sob o X11 o que não é legal. Apesar de tudo, ele é melhor integrado com o GNOME e tem uma qualidade superior aos outros, o Pylan é feito em PyGTK e funciona muito bem.

Meu drama é que após redesenhar toda interface do pylan no glade o programa travou, e não consegue mais abrir o xml gerado… Fiquei na mão, abri um bug report, mas perdi a confiança no sistema.

Agora estou aqui, dividido, com uma deadline, estou bastante inclinado a usar WX com python ou QT com C++, e agora ?

Vai uma coca ai ?

O QUE ACONTECE QUANDO VOCÊ ACABA DE BEBER UMA LATA DE REFRIGERANTE:

Primeiros 10 minutos:
10 colheres de chá de açúcar batem no seu corpo, 100% do recomendado diariamente.
Você não vomita imediatamente pelo doce extremo, porque o ácido fosfórico corta o gosto.

20 minutos:
O nível de açúcar em seu sangue estoura, forçando um jorro de insulina.
O fígado responde transformando todo o açúcar que recebe em gordura (É muito para este momento em particular).

Gostaria de recomendar a leitura do resto do texto do blog de onde tirei o mesmo, o vivaotux vale a pena.