[python-madrid] Propuesta

Sat Apr 21 09:06:43 CEST 2012

Puedo prometer y prometo que me he leído todo!! Guau!! Estoy deseando
llegar a la reunión y ver como os tiráis trastos ("de codigo") a la cabeza!

El 20 de abril de 2012 23:48, Aitor Guevara <aitorciki at gmail.com> escribió:

> En fin, creo que esto puede hacerse eterno, porque tiene mucho más que
> ver con gustos personales que con limitaciones técnicas.
>
> Si Twisted fuese inusable y la gente no quisiese "ni tocarlo con un
> palo", llevaría muerto años (lleva casi 10 dando guerra). En cambio en
> la lista de proyectos gordos que lo usan
> (http://twistedmatrix.com/trac/wiki/SuccessStories) veo cantidad de
> cosas no sólo nuevas, sino tremendamente exitosas (HipChat, TweetDeck,
> JustinTV, ...). OpenStack levanta una expectación brutal, y ahí lo
> tienes, Twisted de los pies a la cabeza.
>
> Evidentemente, que otros lo usen o no no lo convierte en bueno o malo,
> pero la gente detrás de esos productos precisamente tontos no son.
>
> Varios puntos que se han tocado estos días, y como lo veo yo, por si a
> alguien le interesa (lo que sigue es un buen tochaco, avisados
> estáis):
>
> * Twisted es complicado, no es Pythonico
>
> Sí pero no :) Escribir software de red asíncrono de cierto tamaño es
> complicado, se use la herramienta que se use. Si alguien cree en
> librerías mágicas que eliminan toda la complejidad y permiten crear
> sistemas para cientos de miles de usuarios como si fuese un script
> chorra, se equivoca, y punto.
>
> Que la herramienta me permita trabajar de manera más eficiente,
> pudiendo escribir menos (Python es muy expresivo) y facilitando que el
> código sea legible (Python desde luego apuesta por esa vía), perfecto.
> Que pretenda "ocultar" la complejidad inherente al sistema ya no me
> gusta tanto, eso no suele acabar bien. Y no acaba bien porque cuando
> las cosas empiezan a petar bajo carga, es muy probable que los errores
> ocurran fuera de mi comprensión del sistema, y ahora ves a entender la
> magia que hace la librería x.
>
> Del famoso Zen de Python, mi afirmación favorita es "Explicit is
> better than implicit." Creo que es lo que distingue a Python de Ruby,
> donde mucha magia ocurre de manera implícita. Twisted es explícito en
> su tratamiento de la asincronía, sí, y eso para mí es bueno. Más
> cuando mi modelo mental de asincronía encaja muy bien con lo que
> propone Twisted.
>
> * Twisted es un framework, te obliga a hacer las cosas a su manera, eso es
> malo
>
> Sí pero no :) Entiendo que, según las necesidades del software que se
> escribe, Twisted es matar moscas a cañonazos. Como lo es usar Django
> para según que aplicaciones web pequeñas. Pero no parece que a Django
> o Ruby on Rails les vaya mal por ser frameworks, parece que a la gente
> les son bien útiles.
>
> Si sólo quiero hacer unas cuantas peticiones HTTP a un servicio de por
> ahí, mover toda mi aplicación al modelo reactor / deferred de Twisted
> es una locura, sin duda. Ahora bien, si pretendo escribir un proceso
> que sirve HTTP y HTTPS, además de ser cliente de otro servicio web,
> que ofrece una interfaz SSH a su estado de ejecución, usa su propia
> política de resolución de DNS por temas de geolocalización y cache, y
> que también es servidor de WebSocket, Twisted es excelente. Es
> excelente porque ese programa es, en el 90%, código de red que implica
> varios protocolos como cliente y servidor. Puedo usar 8 librerías
> distintas, sí, y hacer que de algún modo funcionen juntas, y adaptarme
> a las peculiaridades de cada una. O puedo usar Twisted y escribir toda
> esa funcionalidad de manera integrada y con un único estilo.
>
> Y no, no es un caso de uso inventado, es el tipo de software que llevo
> años escribiendo para ganarme el pan :)
>
> * Twisted es feo, echa para atrás, nadie querría ni tocarlo con un palo,
> ...
>
> Mmmm, un poco sí, pero no :) Me costó introducirme en el modelo
> Twisted, viniendo del código procedural de toda la vida, habían cosas
> que no me encajaban. Además, todo ese camel case es horrible xD. Pero
> en algún momento se produjo un "click" en mi cabeza (como a la semana
> de usarlo, vamos, no penséis que lleva años) y de golpe todo tenía
> todo el sentido del mundo. El modelo de eventos, los protocolos, las
> cadenas de callbacks, de golpe todo encaja.
>
> Ahora mismo me costaría mucho pensar en código asíncrono de manera no
> orientada a eventos. Los eventos me parecen una manera muy natural de
> pensar: cuando pase x, haz y. No importa cuando sea, no esperes a que
> ocurra bloqueando. Yo te digo que cuando ocurra, quiero que lo hagas,
> y ya está. Como digo me parece muy natural. La sintaxis puede gustar
> más o menos, pero como con todo, es una simple cuestión de costumbre.
>
> * Resumiendo, que es gerundio.
>
> Entiendo que Twisted no guste a todo el mundo. De hecho, no está
> pensado para ser usado en cualquier proyecto, sólo en aquellos
> proyectos donde la comunicación de red es el núcleo del software. Y
> eso es una pequeña porción de todo el software que se escribe.
>
> Ahora bien, llevo cerca de 5 años escribiendo sistemas en Twisted.
> Sistemas que han soportado cargas totalmente locas (en Flumotion
> llegamos a tener cerca de 40Gbit/s de upload haciendo streaming para
> Antena3, TVE y otros). Me gusta Twisted, disfruto escribiéndolo y
> conozco a mucha gente que también lo hace. Es una solución excelente
> para un tipo dado de problema, y no valorarlo como tal por prejuicios
> me parece un error.
>
> Pero al final, todo es cuestión de gustos, si alguien no quiere
> usarlo, por mi perfecto. Pero si alguien tiene curiosidad, mi consejo
> es que no se deje asustar por tanto odio en la lista :)
>
> Ala, my two cents :)
>
> On Fri, Apr 20, 2012 at 20:21, Jesus Cea <jcea at jcea.es> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 20/04/12 20:02, Josep Danti wrote:
> >> Hay algún caso en el que creo que gana twisted. Si se quieren usar
> >> puertos serie,  twisted lo tiene implementado. gevent no lo tiene
> >> por lo que en el primer read se quedaría bloqueado. Habría que
> >> implementar el servicio con greenlets ¿verdad? En general veo que
> >> Twisted tiene más protocolos.
> >
> > Como ya he dicho, twisted es un framework.
> >
> > Resumido, en cuanto tu código toca twisted, tiene que adaptarse a él y
> > se vuelve dependiente, y si quieres usar una librería no soportada, ya
> > puedes reescribirla...
> >
> > Eso provoca que twisted incluya mucho ecosistema alrededor. Pero es
> > precisamente porque no se habla con nadie, así que todo lo que quieras
> > hacer depende de twisted. Básicamente twisted es un mundo aparte,
> > incluyo soporte de muchas cosas porque no es posible usar librerías
> > "normales".
> >
> > Otros proyectos usando greenlets, por ejemplo, y con un simple
> > "monkeypatching" del módulo "socket" (trivial) pueden utilizar
> > CUALQUIER librería de terceros. Naturalmente, estos proyectos no
> > incluyen apenas nada "de serie". No lo necesitan, porque usan
> > cualquier librería python que encuentres y que te venga bien. No es
> > necesario que esa librería esté programada para "twisted".
> >
> > Ejemplo simple:
> >
> > Si mi libreria hace "monkeypatch" de "socket" haciendo que cualquier
> > lectura o escritura se meta automáticamente en un "select" y que ese
> > "greenlet" se pare o se reanude cuando toca, mi programa puede usar
> > CUALQUIER librería de la biblioteca estándar, como "smtplib" para
> > enviar 1000 mensajes en paralelo sin tener que tocar esa librería y
> > sin lanzar ni un solo hilo.
> >
> > Eso con twisted no se puede hacer.
> >
> > Así que sí, twisted incluye muchas cosa de serie... porque no tiene
> > más remedio. Si necesitas algo que no está ahí, o no te gusta cómo lo
> > hace... prepárate a sufrir.
> >
> > En su caso, si manejas el puerto serie como un fichero, puedes usar
> > "select" o similares. Si tienes que hacer muchas más cosas a la vez,
> > greenlets con un pelín de monkeypatching, o una librería específica
> > como gevent o similar.
> >
> > PS: Yo sigo usando "poll" de forma masiva.
> >
> > - --
> > Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
> > jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
> > jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
> > .                              _/_/  _/_/    _/_/          _/_/  _/_/
> > "Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
> > "My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
> > "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.10 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >
> > iQCVAwUBT5GpIJlgi5GaxT1NAQLzxAP/W43EyV82FmbCQuV8WqFTmP9KGIPppSq+
> > udSIn/xtsLWYpA9WsZ9SwTs+t9dxqX7zksd9E8uhE57PnX3x8Oc6OkOnWt6opJ1A
> > Vdn9j0b8C9Fy8CiJmUqODoQmmDIzri6PuMKZa+NcqOSYDL4Hly8gMFIzITEbF9/H
> > bVgIxTEDZIA=
> > =nOTT
> > -----END PGP SIGNATURE-----
> >
> > --
> > Grupo de usuarios de python ubicados en Madrid
> > http://groups.google.es/group/python-madrid
> > http://python-madrid.es
> > http://twitter.com/#!/python_madrid
> > Para darte de baja del grupo envía un mensaje a
> python-madrid+unsubscribe at googlegroups.com
>
> --
> Grupo de usuarios de python ubicados en Madrid
> http://groups.google.es/group/python-madrid
> http://python-madrid.es
> http://twitter.com/#!/python_madrid
> Para darte de baja del grupo envía un mensaje a
> python-madrid+unsubscribe at googlegroups.com
>

-- 
Grupo de usuarios de python ubicados en Madrid
http://groups.google.es/group/python-madrid
http://python-madrid.es
http://twitter.com/#!/python_madrid
Para darte de baja del grupo envía un mensaje a python-madrid+unsubscribe at googlegroups.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.es.python.org/pipermail/madrid/attachments/20120421/c36c7959/attachment.html>