Pylons e TurboGears
Alguns dias atrás, alguém fez a seguinte busca no google: "Pylons é melhor do que turbogears?" e acabou caindo aqui no blog. Dizer qual entre dois frameworks é o melhor é uma tarefa difícil, e pode causar convulsões em algum fanboy (talvez não seja o caso, já que ambos estão ficando em segundo plano por causa do Django, ao menos aqui no Brasil). Porém isso não nos impede de dar uma pequena olhada nos pontos em que esses frameworks se diferenciam e onde está o poder de cada um deles.
TurboGears
O TurboGears é um framework construído por diversas partes (ao contrário do Django, onde toda a stack parte de um mesmo lugar). Atualmente, usa o CherryPy, SQLObject para mapeamento objeto relacional, Kid para templates MochiKit para JavaScript e AJAX. O Framework foi criado por Kevin Dangoor, e teve seu desenvolvimento iniciado no começo de 2005.
Pylons
O desenvolvimento do Pylons começou no início de 2006, e tinha como um dos objetivos, na época, ser uma resposta ao Ruby on Rails, tanto que possui alguns componentes portados do próprio Rails, como o sistema de roteamento de URLS e controladores (Routes) e o WebHelpers. Outra decisão que direciona o projeto até hoje é o fato dele dar extremo valor ao padrão WSGI. Atualmente, o projeto está chegando a versão 0.97. O WebHelpers está sendo praticamente reescrito - a geração de código javascript, e as funções link_to_remote, por exemplo, estão caindo em desuso. Segundo os autores, o framework não deve ser acoplado a nenhuma biblioteca JavaScript, até porque elas estão em constante evolução e a biblioteca da vez sempre muda, o que faria com que sempre alguém ficasse descontente por não ter sua biblioteca preferida suportada. Segundo o Charleno Pires, o Pylons é de certa forma semelhante ao Merb (Ruby), ao prover um framework pequeno e bastante personalizavel.
TurboGears 2
Um julho de 2007, uma surpresa aconteceu: após um sprint, o pessoal do TurboGears decidiu implementar o TurboGears 2 usando o Pylons como fundamento (trocando então o CherryPy). Na época algumas pessoas acharam esquisito implementar um framework sobre o outro (porém, o mesmo acontece com zope, ao pesarmos em CMF>Plone>Archetypes), e houve até uma especulação sobre um possível merge dos dois projetos. Porém, os dois projetos tem propósitos e visões diferentes. Enquanto o Pylons é mais um meta-framework, uma base crua sobre a qual idéias podem ser desenvolvidas, o TurboGears já pressupõe que você irá usar um banco de dados relacional (suposição que o Pylons não faz), possui algumas ferramentas para geração de formulários, ou seja, provê de certa forma uma estrada mais pavimentada para o usuário do framework. Você pode encontrar mais informações sobre o porquê desse merge não ter acontecido na documentação do TurboGears.
E o resultado é...
Entender a história dos frameworks, junto com a experiência de uso deles, é a melhor forma de fazer uma boa escolha. Espero ter contribuído com essa escolha ao detalhar um pouco da história desses dois frameworks!
Links
- Rum - Um 'gerador de CRUD para SQLAlchemy, feito pelo Alberto Valverde.
- Uma introdução ao WSGI - Ian Bicking
- WSGI - a resposta para a questão definitiva sobre Python, a web e tudo mais? - Humberto Diógenes
- Pylons Book Livro sobre o Pylons (em fase de escrita ainda)
- Documentação do TurboGears 2
- Documentação da versão 0.97 do Pylons
por Walter Cruz em Python, Linguagens, Ruby, Rails, Frameworks, Pylons
V8 x Tracemonkey
Ok, depois de compilar o v8, eu pensei: e agora? Após ler sobre o tracemonkey, minha idéia caiu no seguinte: eu compilo o tracemonkey e faço testes com ambos.
Eu adaptei o shell script que roda o benchmark do tracemonkey para rodar o mesmo benchmark, só que usando o v8.
Sobre as duas VMS:
- O lÃder do desenvolvimento do V8 é Lars Bak, que foi o lÃder técnico do Strongtalk e do HotSpot (Java) e também um grande contribuidor da maquina virtual original do Self. Segundo o projeto, o V8 é otimizado para acesso de propriedades e tem um coletor de lixo agressivo.
- O Tracemonkey usa código do Tamarin, a máquina virtual de JavaScript da Adobe, que doou o código para a Mozilla Foundation. A otimização e o JIT é feito usando um processo chamado Tracing Trees. Se você estiver disposto a ler um paper comprido, complicado e interessante, pode ler o Incremental Dynamic Code Generation With Trace Trees.
No geral, o tempo total dos testes foi menor para o tracemonkey, embora comparando os quadros, não teve uma máquina virtual que tenha vencido em todos os testes.
Os testes foram feitos usando a revisão 110 do v8 (disponÃvel em http://v8.googlecode.com/svn/trunk) e a revisão db4260e7ee13 do tracemonkey (disponÃvel em http://hg.mozilla.org/tracemonkey/), e foi usado o próprio benchmark do tracemonkey para testar as duas VMs.
Agora a pouco, eu refiz os testes com as últimas versões das máquinas virtuais, e os resultados se alteraram um pouco:
Diferente do teste do Brendan Eich, foi testado apenas VM e não o desempenho dela dentro do navegador, mas no geral, os resultados do meu teste aqui condizem com o dele.
Mais sobre o v8 e assuntos relacionados
- Benchmarks no Google Chrome (Alexander Limi)
- Ruby rodando no V8
- Tentando aplicar várias técnicas dos novos runtimes de JS para as linguagens dinâmicas da JVM - discussão na lista JVM-Languages, uma lista que agrega muitas pessoas que estão trabalhando em linguagens dinâmicas na JVM (JRuby, Jython, Scala e muitas outras).
- Lua JIT x Javascript
por Walter Cruz em Google, JavaScript, Ruby
Text Munger (ou nem tudo é como deveria ser)
Tudo começou quando eu esbarrei nesse link . O texto contém 15 exercícios de programação, entre eles o que eu me propus a fazer, o text munger.
O exercício consiste no seguinte: dado um texto qualquer, o text munger deve retornar o texto com as palavras desse texto modificadas da seguinte forma: ao invés da palavra original, teremos a primeira letra da palavra original, o resto da palavra (com exceção da última letra) embaralhado seguido da última letra da palavra.
Dentre as várias soluções disponíveis no ruby quiz, a solução em destaque, de Gordon Thiesfeld, usa a expressão regular \b para dividir as palavras. Expressões regulares são iguais em qualquer linguagem, certo? Bom, quase certo. O b funciona da mesma forma no ruby, perl e php, mas funciona de forma diferente no python. Ou não funciona. Na verdade, não sei se é um bug da implementação ou algo assim.
Eu poderia usar outra regex para dividir as palavras e as pontuações, mas já que o fato do \b não funcionar tinha me deixado frustrado com as regex (e eu não queria pensar muito nelas, pra mim o \b deveria funcionar), parti para outra solução. Descobri o shlex, um analisador léxico simples, que para o que eu precisava, funcionava muito bem.
Minha solução para o problema:
import sys
import shlex
from random import shuffle
def munge(text):
t = shlex.shlex(text, posix=False)
t.quotes = "'"
s = [munge_word(word) for word in t]
print(" ".join(s))
def munge_word(aword):
s = list(aword)
first = s.pop(0)
try:
last = s.pop()
except IndexError:
return aword
shuffle(s)
return first + ''.join(s) + last
try:
s = open(sys.argv[1]).read()
munge(s)
except IndexError:
print("Usage: munge.py file")
Observe que a solução não está 100% igual a proposta em ruby. Devido a junção em (" ".join(s)), acabam aparecendo uns espaços em branco que não existiam no texto original.
Existe ainda uma solução em smalltalk proposta pelo Rodrigo Cacilhas no kodumaro. E você gosta de exercícios assim? Sabe porque o \b na implementação de regex do python não funciona como eu esperava? (ou serão minhas expectativas que estão erradas?). Os comentários estão aí para vocês!
por Walter Cruz em Python, Linguagens, Ruby, Geek life
