Web Frameworks

[Alberto Valverde]

Mario Lacunza wrote:
> El 31 de julio de 2008 13:40, Otto Machado<ottomachado en infomed.sld.cu>
> escribió:
>
>   
>> Hola a todos:
>> He seguido el hilo en silencio, pero sin embargo todavía tengo la duda de
>> cual será el mejor FW para mi tesis. Es un gran projecto que tiene una
>> fuerte dependencia con PostgreSQL. Sucede que estado trabajando con
>> CherryPy
>> pero no me gusta del todo. He leído algo de Django, pero es una
>> complicación
>> trabajar con su ORM, sobre todo cuando hay que hacer cambios en la
>> estructura de la BD (y tendre que hacerlo continuamente, pues se piensa en
>> la futura inclusión de nuevas tablas, etc). Me pregunto si Web2Py será
>> mejor, o si ambos (django y web2py) soportan trabajar con SQLAlquemy (que
>> según he leído aquí esta muy bueno, no?). Por favor díganme que creen.
>> Saludos, sandor
>>
>>
>>
>>     
> Y yo sigo en las mismas... tambien estoy entre Pylons, web2py y no se q
> tanto mas q se ha mencionado... :D
>
> Alguien se anima a recomendar alguno?
>   
Vale me voy a mojar... a riesgo de emocionarme y que luego me caigan
collejas por todas partes :). Primero mencionar que he trabajado (en
proyectos por los que cobraba, no siguiendo tutoriales...) con unos
cuantos frameworks python: turbogears 1, web.py, pylons, django,
cherrypy 2 y 3 y varios en los que no he usado ningún framework sino
librerías sueltas (webob, routes, sqlalchemy, genshi...).

El que más me ha gustado es sin duda Pylons ya que trae lo justo para no
tener que escribir demasiada infraestructura pero no toma demasiadas
decisiones por ti. Es decir, puedes usarlo con el sistema de plantillas
que más te guste, con el ORM que más te guste, etc... También sigue la
filosofía de turbogears en cuanto a no reinventar la rueda y reutilizar
librerías existentes, es más, los componentes que han tenido que
escribir (por ejemplo Routes o WebError) los distribuyen como paquetes
independientes de Pylons para que se puedan reutilizar facilmente. Por
cierto, tiene el mejor depurador integrado en web (WebError) que he
visto. En el que incluso puedes evaluar código en cada frame de un
traceback para indagar que es lo que ocurre (funcionalidad que hecho
mucho de menos todos los días trabajando con Django :( )

La prinicpal desventaja es que no es bueno para empezar. Necesitas saber
algo de tecnología web y python para poder empezar a usarlo y
apreciarlo. No por nada especial que tenga su diseño, sino porque la
documentación que hay (por ciero, va a salir un libro dentro de poco,
googlear que hay un draft público por ahí) no va enfocada a
principiantes, es decir, presupone que sabes la diferencia entre un
GET/POST, que es una cookie, para que sirve, que es una sesión, como es
el ciclo de un request... A ellos le gusta decir que es un framework
hecho por hackers para hackers ;)

La arquitectura es muy buena ya que cada aplicación es una instancia en
vez de un singleton global (¡chupate esa django/tg1! ;) por lo que
puedes tener varias aplicaciones WSGI *enteras* (es decir, las puedes
testear o montar por separado ya que también funcionán) conviviedo en el
mismo proceso con distintas configuraciones, incluso de la misma
aplicación. Ésto me ha salvado el pelo en una ocasión en la que el
cliente pidió poder dar acceso a una aplicación existente a varios
clientes suyos pero cada uno con un diseño ligeramente distinto y acceso
a una base de datos distinta.  Tengo entendido que zope también comparte
este rasgo. También permite montar cualquier aplicación WSGI *dentro*
del contexto de la aplicación Pylons. Por ejemplo, en toscawidgets.org
tengo montados dentro de una aplicación Pylons varios Tracs y Mercurial,
al estar dentro del contexto de la aplicación que los envuelve todo el
site comparte autentificación (tanto digest como por formulario/cookie)
y theming.

Por cierto, bittorrent.com y reddit.com (dos sitios con mucho tráfico)
están construidos sobre Pylons, vamos, que es un framework "serio" que
puede atender a muchas visitas ;)

Otra opción que pronto (cuando salga de alpha) te recomendaría sin
reservas es TurboGears 2. Esta construida sobre Pylons pero la filosofía
es tomar varias decisiones por ti para que puedas arrancar más rápido y
enfocar la docuementación a principiantes, pero sin impedir que puedas
"tunearlo" como podrías hacer con Pylons a secas. Por ejemplo, usamos
SQLAlchemy como ORM oficial y Genshi como sistema de plantillas (este
ultimo facilmente intercambiable por mako o jinja si te gustan más).
También estamos reutilizando varias tecnologías de Zope (transacciones
con two-phase-commit, autentificación extensible, etc...) que los chicos
de repoze estan molestandose en desacoplar de la bestia parda... Se
puede decir que Pylons es a Debian lo que TurboGears 2 es a Ubuntu, má o
meno...

web.py también me gustó mucho por su minimalismo. Es el lo más parecido
que he visto en python a php en el sentido de que para hacer algo
sencillo muy rápido no tienes que aprender las idiosincracias de todo un
framework. Si no consigues aprenderlo en una tarde deberías cambiar de
profesión... ;) Sin embargo, tuve que hacer un proyecto para ellos en el
GSoC del año pasado y sí que eché de menos muchas cosas de un framework
(scripts para deploy, logging, shell interactivo, ORM etc...) que acabe
reimplementando yo solito con las perdida de tiempo que conlleva.

cherrypy, me gusta su minimalismo pero me desagrada enormemente como
mapea urls a arboles de objetos ya que te dicta la organización interna
del código en función del interfaz externo (los urls). CherryPy 3 es un
muy buen mini-framework (para quien le guste sus dispatch) e incluye un
servidor web HTTP/WSGI muy bueno (que reutiliza, err, copia en su tronco
web2py por ejemplo)

tubogears 1 me gustó mucho, hace tiempo, aunque ya no lo uso apenas
salvo en aplicaciones que hay que mantener. Me he pasado a pylons para
casi todo. Una cosa que hace muy bien es la negociación de contenido: En
TG1 los controladores suelen devolver un diccionario con datos que luego
TG, en función de las cabeceras del cliente y alguna cosa más, envía a
una plantilla para generar HTML o XML o convierte a JSON. Esto permite
ahorrar bastante codigo ya que la lógica del controlador es la misma
para cada tipo de salida. Lo que no me gusta es su arquitectura de una
aplicación como singleton por cada proceso.

Django. Voy a ser sincero. No me gusta, nada, aunque seguramente sea por
motivos más viscerales que otra cosa... trabajo con el a diario. Aquí va
un rant argumentado:

- el lenguaje de plantillas me parece horrible, por el simple hecho de
no permitir expresiones. Sé como lo justifican en la documentación (y
repiten mecanicamente todos a los que dialecticamete me he enfrentado
por el tema): "No es bueno mezclar lógica y presentación",  "Si quieres
un lenguaje potente de plantillas pasate a PHP", y burradas por el
estilo. La cuestión es que *es* necesaria cierta lógica para la
presentación: bucles para hacer listas/tablas, formateo de fechas,
textos, etc... y no me gusta tener que ir a la docuementación, o saturar
aun más mi escasa memoria, para ver que maldito filtro "emula"
itertools.groupby, o datetime.strftime, etc... Me parece antipythonico
que me quieran cortar las alas argumentando que es por mi bien, para que
no hagas consultas a la bbdd desde la plantilla y cosas por el estilo...
gracias pero soy mayorcito. Al final, tener un lenguaje de plantillas
capado te fuerza a mover toda la lógica a los "views" y tener que
escribir uno distinto para cada tipo de salida. Me gusta mucho más como
hace ésto TG: el controlador manda un diccionario con *datos* y luego
cada vista (que se corresponde a la plantilla) los magrea como vea
necesario para presentarlos (en XML, HTML, JSON, RSS,...)

- El orm. No está mal para modelos sencillos, pero me parece ridículo
seguir pintando a la mona cuando SQLAlchemy está años luz y se escapa
rápido. ¿Para cuando el multi-db, two-phase-commit, sharding, llaves
primarias no numéricas, llaves compuestas, unicode por defecto, etc...?
SQLAlchemy ya lo tiene desde hace tiempo y la comunidad alrededor es
enorme. ¿No sería más fácil adaptar el API de metadatos que genera el
Admin y tener a SA under-the-hood? ¡No por dios! ¡Eso es reutilizar
código de terceros! ;)

- No es multihilo. El GIL no es excusa: la mayor parte del tiempo de una
petición web transcurre en la base de datos y casi todos los drivers
están escritos en C y liberan el GIL cuando la aplicación espera el
resultado de una consulta. Hemos comprobado empiricamente que el mejor
rendimiento de una webapp python en una sóla máquina multi-core se
obtinene con una mezcla de varios procesos con varios hilos cada uno. No
estoy defendiendo esta arquitectura frente a arqutecturas asíncronas,
sencillamente que el modelo de concurrencia que tiene django sí se
presta a multithreading y si no lo tiene es por... me reservo la
especulaciones.

- Pero mi queja principal (a nivel filosófico, no pgragmatico) es la
poca disposición, que percibo, en su comunidad de desarrolladores por
trabajar con el resto de la comunidad webdev python. Al parecer Django
*es* la comunidad webdev python y ni siquiera el sabio abuelo zope
existe, desgraciadamente esta actitud transpira a los usuarios
primerizos que se ven privados por su propia decisión del mundo que hay
fuera de sus jardines... sigh. Compara esta actitud con los de Zope, que
está trabajando en desacoplar su tecnología para que los demás la
podamos reutilizar, or Pylons, que directamente escribe sus componentes
como piezas sueltas con los que en una tarde te puedes escribir tu
propio framework.

(Ya acabé, pido disculpas a los fans de Django por adelantado,
necesitaba descargarme... lo sufro a diario :)

- web2py. No lo he usado pero me contrataron hace un tiempo para
evaluarlo para un proyecto (leyendo las fuentes y escribiendo algunas
aplicaciones de jueguete). No necesité leer más de 3 módulos... Lo malo
de Django (reinventarlo todo en un bloque monolítico, aderezado con
grandes dosis de marketing) sin las ventajas (código precioso, bien
comentado). No lo recomiendo.

Si sigues considerando como opciones sólo a Django y web2py no te lo
pienses: Django. No hay color. Si no me crees haz este experimento: Coge
dos módulos al azar de cada uno, (leete la cabecera no vaya a ser un
módulo externo integrado, si lo es coge otro), y compara el aspecto
estético del código, luego los docstrings, luego los comentaros... mira
a ver si tiene unittests, cuantos...

Espero que te sirva de algo,
Alberto
_______________________________________________
Lista de correo Python-es 
http://listas.aditel.org/listinfo/python-es
FAQ: http://listas.aditel.org/faqpyes