CDPedia, un poco de historia

Python — Sábado 27 de Agosto de 2011, 09:11


Con motivo de la reciente liberación de la versión 0.7 y algo más, me puse a pensar un poco sobre la historia de la  CDPedia.

Cuenta la leyenda (?) que todo arrancó en el sprint posterior al primer PyDay de Santa Fé; la idea la trajo el omnipresente Leito Monk, pero parece que había surgido del Gran Nico César. No sé, ustedes vieron como son los mitos.

Sprinteando en un bar

(éramos tan jovenes...)

La cuestión es que ahí se arrancó el proyecto. Creo que estuvo en un par de SVNs por ahí (o algún CVS?) hasta que terminó en donde está ahora hosteado el proyecto. Las mejoras en el proyecto fueron muy por ráfagas. Recuerdo que siempre se trabajó mucho en este proyecto durante los PyCamps (los dos en Los Cocos, el de Verónica, y el de La Falda), donde muchas personas le dedicaron un buen tiempo, pero también se realizó bastante durante otras reuniones.

Recuerdo, a modo de ejemplo, dos sprints: uno fue en un incipiente hacklab, donde (principalmente) Lucio y Nubis experimentaron sobre el índice para las búsquedas, y también durante la fundación de Wikimedia Argentina, donde presentamos por primera vez el proyecto y trabajamos en la primera parte del procesamiento de datos.

Una gran característica de la CDPedia, indiscutiblemente el proyecto más grande y más largo de Python Argentina, es que siempre se mantuvo orientado al mismo objetivo: tener una wikipedia offline con fines sociales (distribuir en escuelas sin conexión a internet, que el conocimiento sea libre, etcétera), pero sin dejar de que sea divertido (es decir, hacerlo en Python), y manteniendo libre el proyecto (no sólo el producto final, que recomendamos copiarlo y repartirlo, sino el código en sí).

Hasta el 2009, los avances fueron como conté, esporádicos. Pero resulta que Martín Varsavsky se casó, y Jimmy Wales le regaló para el casamiento la posibilidad de que se distribuya una wikipedia offline en Argentina. Preguntó cuales habían, la CDPedia era la que se mejor ajustaba a lo que se necesitaba, y vino Jimmy a Buenos Aires, le mostramos la CDPedia, y luego hubo una reunión en Educ.ar para terminar de acordar esto (fueron Jimmy por Wikimedia, Enrique Chaparro por Wikimedia Argentina y Alecu por PyAr).

Trabajando en el PyCamp

(hagan click en la imagen para ver la foto original, si están curiosos con lo que dice el pizarrón)

En parte porque Educ.ar quería meter la CDPedia en un disco de ellos (con carátula de ellos, algunas otras páginas, etc), y en parte porque nosotros vimos la oportunidad, logramos que dos chicos de PyAr, Diego Mascialino y Hernán Olivera, sean becados para trabajar part time en esto.

Así que agarraron la versión 0.6 que recién había salido (con Alecu nos habíamos apurado a cerrar muchos detalles para tener algo presentable y funcionando a Jimmy Wales), y le entraron a darle. Esto le dio bastante impulso al desarrollo del proyecto, sumado a que yo también por esa época tomé el compromiso interno de trabajar regularmente en esto, y a que luego de que se terminara la beca Diego siguió trabajando en el proyecto, y que se sumó como "laburante regular" Santiago Piccinini.

Con todo este trabajo, y un nuevo "empujón" en el PyCamp del 2011, pudimos terminar de cerrar la versión 0.7, que entregamos a Educ.ar y debería estar distribuyendo por estas semanas a todas las escuelas del pais.

Para minimizar la injusticia de haber nombrado solamente a algunas personas en el texto anterior, para que se den una idea de la magnitud del proyecto (y a riesgo de aburrirlos), les dejo la lista del resto de personas que trabajaron de una u otra forma en el proyecto: Agustín Henze, Antonio Lenton, Alejandro David Weil, Claudio D. Freire, Ezequiel Diaz Marquez, Felipe Lerena, Gonzalo Delgado, Gonzalo García, Guillermo Gonzalez, Hugo Ruscitti, Lucio Torre, Marcos Dione, Martín Gaitán, Maximiliano David Bustos, Nicolás Miyasato, Pablo Ziliani, Piukeyen Tappa, Ricardo Kirkner, Sebastian Farioli, y Zuzel Vera Pacheco

Para terminar, les cuento que puse una versión menos personalizada de este texto en el wiki de PyAr, para que aquellos que recuerden más y más detalles los agreguen ahí.


Distribuyendo un programa hecho en Python

Python — Miércoles 22 de Junio de 2011, 17:56


Más que un análisis completo de las tecnologías para permitir la distribución de programas hechos en Python, este post es casi una receta o colección de anotaciones para seguir un camino. Y es que es un camino que no me fué fácil recorrer, porque la mayoría de los mecanismos para distribuir código Python están pensadas para distribuir bibliotecas hechas en este lenguaje, y no programas.

¿Dónde está la diferencia? En dónde van las cosas.

Antes de seguir: para todo el armado usé distutils, que es lo que está en la biblioteca estándar. Le pegué una mirada a otras cosas como setuptools, distribute, etc, pero todas (aunque son más aptas para cosas más complejas) no me solucionaban el problema básico y me complicaban un poco la vida en otros aspectos.


¿Dónde van las cosas?

Volviendo a el lugar en dónde se instala el código Python... si uno quiere distribuir una biblioteca, la respuesta es sencilla: en el directorio de bibliotecas de Python de tu sistema. ¿En dónde particularmente? Bueno, depende de tu sistema; incluso en Linux esto fue cambiando y no es el mismo lugar siempre. En mi máquina tengo /usr/lib/python2.6/dist-packages/, que en parte apunta a /usr/share/pyshared/.

Igual, no importa la ubicación exacta: usando distutils (u otras alternativas) las bibliotecas van a parar al lugar correcto sin mayor esfuerzo.

¿Pero qué pasa si no es una biblioteca sino un programa? El primer detalle es que necesitamos un ejecutable que arranque nuestro programa. Distutils y amigos tienen esto bastante bien manejado, se les puede especificar un script, y terminan instalando todo de la siguiente manera:

  script -> /usr/bin/
  todo el resto /usr/lib/python2.6/dist-packages/ (o similar)

Hasta acá todo bien, ¿no? No. Resulta que nuestro programa tiene imágenes, archivos de audio, etc, y está "mal visto" meter esos archivos "de datos" dentro del directorio de bibliotecas de Python. Entonces, lo que recomiendan por ahí es:

  script -> /usr/bin/
  archivos de datos -> /usr/share/
  código python -> /usr/lib/python2.6/dist-packages/ (o similar)

Esto ya no es tan fácil de lograr, porque la distribución de archivos de datos es como un parche en los sistemas de distribución de bibliotecas.

Además, si nos vamos a poner quisquillosos de no meter archivos de datos en el directorio de bibliotecas, yo pregunto: ¿por qué meter código de nuestro programa, que no es una biblioteca, en el directorio de bibliotecas?

Entonces me embarqué en el siguiente capricho: quería que la distribución de mi programa vaya a parar a:

  script -> /usr/bin/
  todo el resto -> /usr/share/

Los archivos de datos, por supuesto, mezclados con "todo el resto".


Estructura de nuestro programa

Primero lo primero, ¿cómo organizamos nuestro proyecto? Yo tengo lo siguiente (simplificado, pueden ver toda la estructura en los archivos del proyecto Encuentro):

- un directorio 'bin' donde tengo el script que arranca todo

  bin/encuentro

esto es un archivo ejecutable que no hace mucho más que jugar un poco con los directorios y el sys.path para que se encuentre al resto del código Python de nuestro programa (en dos situaciones: cuando ejecutamos bin/encuentro desde el repositorio mientras estamos desarrollando, y cuando está instalado finalmente en el sistema), e inicializar alguna estructura básica y arrancarla, para que comience nuestro programa.

- un directorio con el nombre de nuestro proyecto, con el resto del programa:

  encuentro/__init__.py
  encuentro/main.py
  encuentro/network.py

- directorios con los archivos de datos, adentro de nuestro proyecto (no por separado), en este caso:

  encuentro/ui/main.glade
  encuentro/ui/preferences.glade
  encuentro/ui/update.glade

Una vez aclarado eso, quedan dos preguntas sencillas y una complicada por contestar: las sencillas son ¿cómo el script encuentra al resto del programa instalado? y ¿cómo accedemos a los archivos de datos desde nuestro código?.

La primera es usando una variable que se inyecta en el script en el momento de instalar el programa (ver más abajo el cuándo hacemos eso en setup.py).

La segunda es accediendo a los archivos de forma relativa al código. Yo tengo esto al principio del programa:

  BASEDIR = os.path.dirname(__file__)

y luego hago cosas como:

  data_file = os.path.join(BASEDIR, 'ui', 'preferences.glade')

Finalmente, la pregunta complicada: ¿cómo hacemos para que todo esto funcione?


Distribuyendo programas

En realidad, la respuesta no es tan complicada una vez que está resuelto (como tantas cosas en la vida).

Para incluir todos los archivos, en el setup.py, en la llamada a setup() hay que poner:

  packages = ["encuentro"],
  package_data = {"encuentro": ["ui/*.glade"]},
  scripts = ["bin/encuentro"],

Fíjense como ahí declaro el paquete donde está mi programa, el script, y los archivos de datos. Pero hay un bug, hasta en Python 2.6 inclusive, que hace que para meter los archivos de datos con eso sólo no alcanza, y hay que declararlos también en el MANIFEST.in:

  include encuentro/ui/*.glade

Para que todos estos archivos vayan a parar al lugar correcto, hay que hacer algo específico: una clase que acomoda cosas en el proceso de instalación. Pueden ver el detalle de esa clase en el setup.py de Encuentro, pero basicamente hace dos cosas:

- Construye un directorio donde va a quedar todo con el prefijo indicado, "share" y el nombre del proyecto, y autocorrije el directorio de instalación con eso.

- Guarda ese directorio de instalación nuevo en los scripts declarados, usando una cadena especial como bandera, de manera que al quedar el script instalado sabe dónde buscar el programa entero.

(importante: no olvidar declarar en la llamada a setup() a esta nueva clase como la clase que será usada para instalar!)

Finalmente, está bueno probar que todo funca bien. Las pruebas que yo hice fue crear el .tar.gz con python setup.py sdist, descomprimirlo en otro lado que nada que ver y hacer python setup.py install --prefix=/tmp (para que se instale en /tmp y probarlo ahí adentro) y también sudo python setup.py install (para que se instale en el sistema y probarlo así).

También, luego de hacer todo el proceso de packaging, cuando pbuilder me dejó el .deb, lo descomprimo y veo que la estructura está correcta y que la variable reemplazada en el script tiene el valor que debería; igual, la prueba de fuego con el .deb es instalarlo con dpkg -i y probar el programa.

Nota final: ahora me falta armar un .exe para que se pueda ejecutar en Windows, pero eso será otro post.


Enjuewemela 0.3 está en la calle

Python — Sábado 21 de Mayo de 2011, 16:56


Enjuewemela es aún otro juego similar a los populares "Bejeweled" o "Diamond Mine". El juego se basa en alinear 3 o más gemas, tanto verticalmente como horizontalmente, intercambiando gemas adyacentes. Está (por supuesto) escrito en Python, usando el framework para juegos cocos2d.

La versión 0.3 trae un montón de nuevas características, y muchos bugs corregidos. Lo pueden descargar de acá.

Noten sin embargo que todavía es una liberación pre-alfa: tiene un montón de detalles a mejorar, y necesita mucho amor a nivel de "arte".

Algunos de los cambios más grandes son:

- Modos de juego Clásico y Apurate! Prueben ambos, se van a divertir, :)

- Las gemas explosivas y mágicas están completamente implementadas.

- Completo soporte para internacionalización.

- El puntaje se graba por tipo de juego, y hay una pantalla de Puntajes Máximos.

- No más límite para los niveles de juegos.

- Las piezas son seleccionables, o se pueden mover arrastrándolas.

- Los puntajes se indican como burbujas al lado de la gema seleccionada.

- El flujo general del juego está terminado, incluyendo el menú completo de "opciones" y una pantalla de "créditos".

- Ahora se puede salir con ESC, y pausar el juego con "p" o la tecla de pausa.

Para más información, pueden visitar la página del proyecto.


PyDay en Córdoba

Python — Martes 03 de Mayo de 2011, 17:01


El sábado pasado se hizo un nuevo PyDay en Córdoba. Algunas fotos acá.

Salí en avión el viernes a la tarde, en un vuelo que tuvo demora pero que me dejó en Córdoba a las seis y monedas. Me tomé un bondi, pasé un rato por lo de Naty y Matías, y me fui a cenar con Roberto Allende y Daniel Valfre, volví y a la cama

El sábado nos levantamos tempranito y fuimos hasta la UTN con Matías (Naty venía más tarde). Llegamos, nos registramos, y empezamos a reencontrarnos con tanta gente que uno se reencuentra en estos eventos.

Las charlas del PyDay estaban separadas en dos tracks, principiante y avanzado. Así que al rato me metí en la sala donde eran las avanzadas y me quedé ahí hasta el mediodía.

Instrucciones y programa

Algunas charlas que me interesaron: sobre NLTK y procesamiento de lenguaje natural, por Pablo Duboue y Rafael Carrascosa, realmente muy interesante todo lo que se puede hacer; una sobre Python, Sugar y robótica, por Valentín Basel, muy groso controlar un robot físico con lo que es la evolución del Logo; una sobre MyHDL por Martín Gaitán, donde vimos como diseñar silicio usando Python; y una sobre DBus por Alecu, un tema que más o menos ya sabía pero siempre se aprende algún detalle.

Luego vinieron las lightning talks, mi plenaria sobre "Comunidad, anarquía y subversión", y el cierre. Estuvo muy bien el evento.

Al toque salimos varios caminando hacia Nueva Córdoba, una zona a unas quince cuadras de la Universidad donde podíamos encontrar algún lugar para tomar algo. Algunos sólo tomamos una cerveza, porque después volvíamos a la cena armada para los disertantes y organizadores, pero otros se quedaron a comer ahí, especialmente porque volvían esa misma noche a sus hogares y no les daba el tiempo.

Así que sólo cuatro nos volvimos de ahí para la Universidad (esta vez nos tomamos un taxi porque estaba mucho más frío el asunto, y el camino era largo y duro (?)), y fuimos los primeros en llegar al lugar. Aprovechamos y arrancamos con unos metegoles, y ahí fue cayendo la gente.

Mucha charla, partidos de ping-pong (hay que banear a Matías Herranz de cualquier torneo de ping-pong: nos pasó el trapo a todos), cerveza y choripán, más charla, etc... una cena muy copada.

La gente se fue retirando, y los más jóvenes (?) decidimos que la joda siguiera... bah, Perrito me dijo "vamos a tomar un café" y ahí arrancamos para otro lado. Terminamos yendo Perrito, Nueces, Anggie, su novio Catriel, y el que suscribe a un lugar a tomar un trago. Y más y más charla, hasta que el frío y el día largo hicieron estragos suficientes, y emprendimos la retirada (Perrito me hizo la gauchada de llevarme hasta lo de Naty).

Al otro día, me levanté tempranito, me pegué un baño y preparé todo, desayuné con Naty, y de ahí al aeropuerto, y a casita, con la familia.


Adopte un newbie

Python — Miércoles 06 de Abril de 2011, 12:45


En el último PyCamp Pablo Mouzo tiró la maravillosa idea de que aquellos con mucha experiencia dando charlas podíamos ser mentores de gente que se iniciaba por ese camino, para dar consejos, transmitir experiencia, etc. Yo me propuse como mentor para aquel que quisiera proponer una charla en cualquiera de los eventos de PyAr.

Pero a ese concepto Mariano Guerra se le dió otra vuelta de rosca, y armó una página en la que personas con buena experiencia en PyAr o Python se proponen como mentores, los newbies se proponen como mentados, en función de los perfiles de los tutores, y luego los mentores aceptan dedicar una cantidad de tiempo semanal a las consultas del mentado (por mail, IM, en persona o lo que se decida), el mentado acepta documentar sus pasos de aprendizaje en un blog y a dar una charla en el evento en el que se considere que entraron en la "adultez pythonistica".

Mentor

Ahí es donde me puse a pensar que en mi (poco) tiempo libre empujo (o trato de empujar) algunos proyectos que son bastantes variados entre sí, y que pueden ofrecer una buena oportunidad para que alguien arranque y se ponga a aprender, no tanto Python, sino como trabajar en un proyecto.

Como verán abajo, hay uno que está en castellano y el resto en inglés. Uno hosteeado en Google Code, uno en Trac, el resto en Launchpad. Algunos con lista propia, otros no. Algunos con más tests, otros con menos. Diverso.

Y creo que los proyectos son lo suficientemente variados como para que sea más fácil elegir :).

- CDPedia: Es un proyecto de Python Argentina para tener la información de la Wikipedia en castellano accesible aunque no tengas una conexión a Internet.

- Lalita: Yet another IRC bot, one where new functionality is simple to create by just adding easy-to-write plugins.

- Enjuewemela: Crazy game with a lot of gems that tend to disappear strangely following user actions

- Magicicada: A GTK+ frontend for the "Chicharra" part of Ubuntu One client.

- Python: Acá la idea es trabajar en el proyecto Python mismo (lo que puede ser código Python o C, o incluso no código sino documentación, etc.), no hacer cosas con Python.

- Twisted a Python 3: Estoy empujando el migrar Twisted (an event-driven networking engine) a Python 3. Esto no es un proyecto en sí, sino que está en el marco de Twisted mismo.
 
Así que ya saben, si les interesa meterse en alguno, me avisan. En general la coordinación sería remota (IRC, IM), así que no necesitan estar en Buenos Aires...


PyCamp 2011, en La Falda

Python — Martes 29 de Marzo de 2011, 21:32


El fin de semana pasado, que era largo  (¡cuatro días!), lo pasé en La Falda, Córdoba, junto con un montón de gente copada, disfrutando del cuarto PyCamp de Python Argentina.

No voy a explicar de nuevo que es un PyCamp, pero pueden ver mis posts de las ediciones anteriores(acá, acá, y acá).

Viajé en micro durante la noche, así que tempranito ya estaba allá... es más, fui el primero en llegar. Luego fueron cayendo un par más, pero había mucha gente varada en Córdoba Capital por un paro de transporte (gente de Córdoba mismo, y gente de otros lados que cambiaban de micro allá).

Pero más tarde terminaron llegando, y entre una cosa y la otra nos fuimos terminando de empezar a organizar. Así que almorzamos, y arrancamos contando los proyectos que queríamos empujar, quienes éramos, etc.

Después de comer arrancamos varias personas laburando en la CDPedia, un proyecto al que le dedicamos buena parte de los cuatro días. La verdad es que tantas horas invertidas tuvo un resultado bárbaro: corregimos varios problemas, le agregamos muchas características, e incluso terminamos todo lo necesario para sacar la versión 0.7; sólo nos queda limar algunos detalles y ya estaríamos sacando la versión final para distribuir y ver si todavía estamos a tiempo de que Educ.ar las distribuya este año.

Trabajando

El viernes arrancó el día conmigo dando una charla de Twisted que no era mía. Había mucha gente que quería aprender algo de Twisted, y se iba a utilizar en varios proyectos, entonces se me ocurrió, aprovechando que teníamos un microproyector que había traído Achuni, dar la charla que Lucio preparó para las Charlas Abiertas de La Tribu.

Uno de los proyectos de Twisted era seguir portándolo a Python 3, que yo empujaba. Nueces se copó y laburó en esto mismo, conmigo. Durante el día logré terminar un branch que había comenzado durante el sprint en PyCon, y Nueces también logró terminar su parte, generando varios parches. Fue bastante productivo, y encima lo que hice yo y parte de lo que hizo Nueces fue tomado por los desarrolladores del proyecto y metido en trunk (a esta altura ya debe estar metido todo).

Esa noche salimos con Perrito y Joac a comprar un Legui, pero no encontramos, así que nos volvimos al hotel con fernet, coca cola e hielo, y estuvimos varios jugando a un juego de computadora, en red, que no conocía y que me encantó: Armagetron Advanced, que es un juego que salió de la película Tron.

El sábado se hizo un bug day doble, de Python y Django, tanto presencial en el PyCamp como remoto, coordinado por IRC. Tengo que preguntarle a Ramiro Morales para ver cómo salió el de Django (él coordinaba ese); el de Python estuvo bastante flojo porque más que corregir bugs estuvimos charlando y discutiendo cómo usar Mercurial aplicado al proyecto de Python, que no es algo sencillo de determinar, y todos los desarrolladores están ajustando el workflow para ver cómo se puede laburar mejor. Así y todo, para mí estuvo productivo porque no conocía casi nada de Mercurial, y me llevé un buen pantallazo general.

A la tardecita hicimos un paseo entre todos: nos fuimos caminando hasta el punto turístico de La Falda: el Hotel El Edén, donde vimos un video con la historia del lugar, tuvimos un paseo guiado, y hasta una ínfima degustación de vino y queso (muy ínfima). No estuvo para nada mal el paseo.

Hotel El Edén

Durante la vuelta, picamos en punta con Perrito y Pablo Mouzo y pasamos por un supermercado para comprar unos vinos, porque esa noche cenábamos en el salón donde trabajábamos (nos traían las pizzas hasta ahí), ya que durante la cena tuvimos la reunión de PyAr número 48. Tratamos varios temas, y la discusión estuvo muy buena, fue una fantástica reunión.

El domingo fue un día mucho más tranquilo, se notaba que estábamos todos muy cansados. Laburé en CDPedia un rato, charlé de varias cosas con varios, pero nada muy intensivo. Durante la tarde hicimos una actividad grupal: fuimos recorriendo los proyectos en los que se había trabajado durante el PyCamp y en unos minutos se contó qué se hizo, qué se logró, etc.

Los que más me gustaron fueron el grafo del wiki de PyAr (un grafo donde los nodos eran las páginas del wiki y se mostraban las relaciones entre ellas, muy bueno), faldatouch (algo desarrollado cien por ciento durante este PyCamp: una biblioteca que ofrece tener muchos punteros (como si fueran de mouse) a una aplicación, pero con la capacidad de manejar estos punteros desde cualquier lado, particularmente desde teléfonos o páginas web), y la biblioteca de moda: Pilas.

Pilas es un framework para hacer juegos, orientado a que sea sencillo e intuitivo de usar (y con la característica de estar en castellano, lo cual simplifica mucho su adopción por alumnos de escuela primaria) pero a su vez muy poderoso. Se hicieron tres cosas muy piolas sobre Pilas en este PyCamp: se armó lo básico para que se pueda internacionalizar (ahora todos los comandos pueden estar en cualquier idioma), se integró con la biblioteca OpenCV (con lo que se puede tener uno o más videos, incluso el que toma la webcam de la compu, como objeto para manejar durante un juego), y se le armó una especie de multisesión exploratoria (basicamente la capacidad de que mucha gente se conecte a una misma máquina y tenga un intérprete interactivo en el mismo espacio de nombres que la máquina que sirve, con lo que se puede explorar Pilas al mismo tiempo por todos los conectados, de forma colaborativa).

Después de esta sesión se armó el segundo torneo del PyCamp: Armagetron Advanced; el primero fue un campeonato de metegol, :)

Y ya nos fuimos aflojando, boludeamos un rato, preparamos las cosas, y nos fuimos yendo de a poquito (todos salíamos a distintos horarios).

Como conclusión: siempre digo que PyCamp es uno de los mejores eventos de Argentina y del mundo... y este no fue la excepción. Ah, acá hay algunas fotos.


PyCon Atlanta 2011, los Sprints

Python — Domingo 20 de Marzo de 2011, 18:31


Cuando me puse a pensar qué podía hacer durante los cuatro días de sprints, al principio no me llamó nada la atención. Pero luego se me ocurrió que podía (empezar a) portar Twisted a Python 3, que era algo que tenía una mezcla de dos cosas en la que me quería meter: más adentro de Twisted que lo que te da el uso diario, y en Python 3 usándolo en casos no triviales.

Más puntualmente, mis objetivos para los sprints eran:

- Meterme adentro del código de twisted: Conocer la estructura del proyecto, detalles del código, etc.

- Conocer más sobre el projecto de Twisted en sí: conocer más y charlar con los desarrolladores, meterme en el proceso de desarrollo que ellos tienen montado alrededor del proyecto, etc.

- Tener problemas reales (más allá de la teoría) al portar a Python 3, enfrentándome a casos complicados que no aparecen cuando uno estudia la documentación.

- Lograr que al menos un test corra OK en Python 3 (lo que implica que toda la infraestructura de pruebas funcione en la nueva versión, lo cual está lejos de ser sencillo porque esa infraestructura misma es provista por twisted).

En los días anteriores había bajado el trunk del proyecto, para irme familiarizando, y al correr los tests encontré que me fallaban algunos; luego de analizar y ver qué pasaba terminé descubriendo que era por un problema del código que dependía del locale de la máquina (y como yo la tengo en castellano, explotaba ahí). Decidí que esa iba a ser mi primer contribución al proyecto, y armé un parche y lo propuse.

No fue tan directo, ya que realmente los tests no fallaban a menos que la máquina estuviese no en inglés, así que luego de charlarlo un rato decidimos que tenía que ponerle unos casos de prueba condicionales, y eso hice. Tampoco entró tan fácil esto, porque faltaban un par de cosas de estética en las que yo no estaba de acuerdo con los desarrolladores de Twisted.

Y es que Twisted es un proyecto muy viejo, y estandarizó algunas cosas que son contradictorias con lo que después se definió como mejores prácticas dentro del mundo Python. Entonces ahí tuvimos algunas idas y vueltas, y al final yo mandé un mail a la lista de Twisted para empezar un cambio, y metieron mi parche en trunk, corrigiendo el problema.

Aunque todo esto llevó bastante tiempo, me sirvió mucho para irme familiarizando con el proceso, cómo manejan los tickets, qué significa cada cosa, etc.; en definitiva, cual es el workflow de los bugs y parches.

Sprinting

Volviendo a los casos de prueba, luego de ejecutar algunos tests en Python 2.6 con el flag -3 detecté algunas cosas que podía empezar a cambiar masivamente, y al mismo tiempo  meterlo en el código actual. En otras palabras, cambios que pegaban en todo el proyecto, y que hacía que esas partes estuviesen mejor preparadas para la migración a Python 3. Uno de estos cambios fue dejar de usar el módulo new y comenzar a usar types, el otro fue dejar de usar cmp (tanto __cmp__, como el builtin, como el parámetro de sort/sorted) y empezar a usar lo que se llama rich comparisons. El primer cambio era bastante directo (propuse un branch, aunque me dijeron que había tocado un par de cosas que no tiene pruebas y tenía que hacer los test), pero el segundo cambio es un quilombo (no llegué a terminar el branch) porque la funcionalidad no es directamente equivalente, sino que depende de qué tipo de comparaciones se quieren realizar.

El tercer día decidí cambiar el enfoque. Lo que estaba haciendo no estaba equivocado, pero daba para mucho más que los dos días que quedaban, y la idea era probar distintas cosas ahí, antes que termine el sprint, aprovechando que estaban los viejos del proyecto cerca.

Así que decidí arrancar con la migración propiamente dicha, postergando las correcciones a lo que ya había hecho. Le corrí 2to3 a todo el proyecto, lo cual me corrigió una gran cantidad de cosas triviales en muchos archivos, dejó intacto muy pocos, y me avisó de cosas que no pudo cambiar que debería tocar a mano (esto quizás se pueda meter en otro branch que funcione también en Python 2).

Finalmente, traté de correr un test con Python 3. Acá empezaron a saltar muchos, muchos detalles. Algunos triviales, y otros bastante espesos.

El primero complicado fue que Twisted depende de zope.interface. Por suerte este ya estaba migrado a Python 3, el tema era hacerlo andar con el Python 3.2 que tenía instalado (Ubuntu Maverick trae 3.1). Al principio quise usar virtualenv pero no había una versión empaquetada para Python 3, así que traté de compilarlo, lo que me llevó a darme cuenta que necesitaba tener setuptools3... en fin, terminé teniendo lo que necesitaba en 3.1, pero no en 3.2. Acá cambié el approach... bajé las fuentes de un virtualenv para Python 3, lo compilé e instalé usando Python 3.2, y ya adentro del virtualenv instalé con easy_install a setuptools3 y zope.interface... y acá quedó andando lindo: Python 3.2, con todo lo necesario. (muchas gracias a Nati y Darni por la ayuda en toda esta gran configuración).

Igual, no terminaba ahí, porque tuve que tocar bastante código ya que cambió la forma de usar zope.interface: antes se hacía implements(IAlgo) en el scope de la clase, y ahora hay que decorar la clase con @implementor(IAlgo).

Otra cosa que me mordió feo es que el método de una clase no es más un unbound method, sino una función pelada que no sabe en qué clase está (obviamente en ambos casos al instanciar la clase, la función se convierte en un bound method). Esto rompe el cómo trial busca los test cases que uno indicó por linea de comandos.

Cuando les comenté este problema a los desarrolladores, empezó toda una discusión de qué podíamos hacer porque corregir esto no es trivial, y va a pegar bastante en todo el código. Finalmente decidí arreglarlo de forma medio sucia... no es la forma final, pero me permitió seguir con lo que yo estaba haciendo. Otro chico se quedó con la tarea de ver de normalizar eso.

Igual, más allá de esos dos problemas grandes, tuve que ir corrigiendo muchos pequeños detalles (hay que tener en cuenta que Twisted es uno de los pocos proyectos que sigue hoy en día habiendo arrancado en Python 1).

Pero finalmente, varias horas después, terminé de corregir todo lo necesario, y pude ver mi primer test que corría OK con Python 3, :D

La verdad es que estaba muy contento, y no sólo yo: los otros desarrolladores también, porque yo no era el primero que decía que se tenía que migrar el proyecto a Python 3, pero sí el primero que se arremangaba y obtenía resultados.

Y hasta acá llegó el sprint... realmente no hice mucho más, excepto ver todos los cambios que había metido y hacer una especie de listita con todo lo que hay que ir sacando de ahí e ir pasando en limpio para mandar al proyecto.  Encima a las tres de la tarde del último día nos cortaban internet, así que básicamente después de almorzar ya estaba con la persiana baja.

Así que me quedé un rato, saludé, me fui para el lobby a usar la internet del hotel para terminar algunas otras cosas, y un par de horas después emprendí el camino de regreso a casa.


PyCon Atlanta 2011, la conferencia

Python — Domingo 13 de Marzo de 2011, 23:12


El formato de PyCon USA este año fue de dos días de tutoriales, tres días de conferencia (dos y tres cuartos, realmente), y cuatro días de sprints.

A los tutoriales no fui, pero sí a la conferencia y los sprints. Este post es sobre esos tres días de conferencia.


Primer día

Luego de la presentación y apertura del evento, tuvimos en la primera charla plenaria a Hilary Mason hablando de programación, análisis de datos, y varias cosas diversas... nada específico, pero entretenido.

Tuvimos un pequeño break y arrancó la primer sesión de charlas propiamente dichas. La primera fue "Distributed Tasks with Celery", por Ryan Petrello. Creo que la idea está buena, claramente resuelve casos de uso que se me presentaron y con los que estuve jugando... pero el diablo está en los detalles, dicen, hay que ver cómo es usar esto IRL.

"Getting more contributors (and diversity) through outreach" por Asheesh Laroia. Estuvo bien, aunque se focalizó más en "more contributors" que en "diversity", que era mi interés. Una idea para diversidad: hacer un evento especial para mujeres... hombres pueden ir, pero tenés que ir invitado por una mujer que vaya. Esto es algo que se inventó y probó en la comunidad de Ruby on Rails y que ha tenido bastante éxito... ya mandé un mail a la lista de correo de PyAr, veremos qué se opina por ahí.

Para dejar clara mi posición al respecto, lo que a mi me interesa es derribar las barreras actuales que evitan que las mujeres tengan las mismas oportunidades que los hombres en todo lo relacionado con tecnología.

La última charla de la mañana estuvo relacionada con la anterior, "Diversity in Tech: Improving our Toolset", por Jennifer Leech. Interesante aspecto relacionado con las expectativas y como estas afectan los comportamientos: "Si vos le decís a una persona cómo esperás que cumpla con una tarea en particular afecta profundamente cómo esa persona cumplirá con la tarea".

Luego el almuerzo, que fue durante la reunión de la Python Software Foundation, y las charlas de la tarde. Me quedé para dos relacionadas con Python 3: "Status of Unicode in Python 3" por Victor Stinner, y "Porting to Python 3", por Lennart Regebro.

Un break, una charla que no me gustó, y luego "Why is Python slow and how PyPy can help?", que no era lo que esperaba pero no estuvo tan mal (se dedicaron a hablar de que PyPy es más rápido que CPython y algunas cosas que hacen a nivel del JIT, pero nada más).

Sala de la plenaria

De cierre, las lightning talks. Alguna te puede gustar, otra no, pero el formato está buenísimo (justamente porque de las que te gustaron luego seguís investigando, y de las que no... bueno, no perdiste más de cinco minutos).

Al rato nos fuimos a cenar Dani Moisset, Armin Rigo (core developer de PyPy), Reid Kleckner que laburaba en Unsladen Swallow mientras el proyecto estaba activo, y yo. Comimos en un restaurant chino que estaba cerquita.

Al volver me puse a laburar en un fix a Twisted, y al sobre.


Segundo día

Al otro día, arrancamos con lightning talks de nuevo. Estuvo buena la de python-on-a-chip, que es una colección de ports de Python a algunos microcontroladores... me llamó la atención particularmente el port a DryOS, que es el sistema operativo de muchas Canon, incluída la que tengo.

También estuvo piola la de Brett Cannon contando que había hecho la nueva guía para desarrollar Python (Python, no en Python), y otro documento sobre cómo portar proyectos a Python 3.

Luego vino una plenaria sobre "How Dropbox did it and how Python helped", la cual estuvo pésima. Habló un poco de Dropbox, habló mucho de él y sus amigos... como charla normal, hubiese estado de medio pelo para abajo, y para una plenaria uno espera más. El flaco, como disertante, pésimo... creo que miró a la audiencia dos o tres veces, el resto leía de la laptop... mal.

Para cerrar el bloque, una entrevista relajada a Guido: básicamente una serie de preguntas que la gente fue mandando y votando a través de una página web. Habló de varias cosas, pero una frase que me encantó fue "The biggest innovation in Python is Community" ("la mayor innovación en Python es la Comunidad").

Luego de un break, comenzó la primer sesión de charlas. Me enteré de detalles históricos en "Ten years of Twisted", por Glyph Lefkowitz, y luego algunas ideas sobre documentación en "Writing great documentation", por Jacob Kaplan-Moss.  Antes de comer, una interesante charla de Alex Martelli, "API Design anti-patterns".

La sesión de la tarde, después del almuerzo,  arrancó con una charla de programación genética usando PyEvolve, y luego una charla sobre memoria: interesante, pero me hubiese gustado algo más de detalle en los internals y menos en lo que hace la biblioteca de este muchacho, gdb-heap. Antes del break cerramos con una charla sobre ZeroMQ... la biblioteca está interesante (una especie de socket mágico que puede ser 1:1 o 1:N, N:1, N:M, y con distintas semánticas con respecto a la respuesta), pero el flaco se la pasó cambiando ventanas, yendo para atrás y para adelante en la presentación a toda velocidad, y la verdad que se hubiese entendido más si hubiese mostrado todo mejor (no más, sólo mejor).

En el último bloque sólo ví una charla sobre AST, que estuvo un poco densa pero me dió más info para algo que tenía en la cabeza... de esos proyectos que uno patea para adelante y realmente nunca empieza, je, maldito día de sólo veinticuatro horas.

Y para cerrar,  lightning talks de nuevo! Se habló de Read the docs, un sitio web que reúne documentación de forma muy piola: basicamente lo apuntás a tu proyecto, y te arma toda la documentación a partir de tus .rst, los sirve, búsquedas completas, descarga como PDF, etc; muy interesante. Barry Warsaw habló sobre flufl.i18n una herramientra de internacionalización de más alto nivel que la clásica gettext.

A la noche cena con Nati Bidart, Dani Moisset y Juan Pablo (un chico de Buenos Aires que no conocíamos... bah, nos vimos un par de veces en algún PyDay) a un mexicano cerca que no estuvo muy bueno.


Tercer día

Nuevamente arrancamos con lightning talks, en las que yo día una charlita sobre PyAr, básicamente hablando de las Charlas Abiertas de Python en La Tribu, y de la CDPedia.

Luego hubieron tres plenarias dadas por sponsors: Threadless, Disqus y OpenStack. La de Threadless estuvo super divertida, y la de Disqus fue interesante del lado técnico, pero nada más.

Torta  de los 20 años

Luego de un break bastante largo (porque estaba la "poster session"... eso de los posters no me llama mucho la atención) fui a la charla de Raymond Hettinger "Fun with Python's Newer Tools", donde habló sobre Counter, namedtuples, lru_cache y .format. Estuvo muy buena!

A la tarde asistí a una charla sobre cómo habían escalado el nuevo frontend de SourceForge, y a una en que Doug Hellmann contaba sobre "tesoros escondidos" de la biblioteca estándar (no estuvo mal, pero ya conocía todos los módulos que comentó).

Para cerrar el evento, más lightning talks y mucha gente desfilando diciendo qué sprint va a liderar, a ver si consigue gente. Yo ya lo tengo decidido antes de venir, voy a empezar a portar Twisted a Python 3.


Conclusión

La conferencia, a nivel charlas, estuvo bien. No hubieron demasiadas cosas que me volaran la cabeza, pero estuvo interesante. Creo que vale la pena venirse hasta acá (aunque quizás no todos los años, por el costo que implica).

Hubo una sorprendente cantidad de "ruido" alrededor de PyPy (el intérprete de Python escrito en Python), porque que alcanzaron un punto de madurez en el que cumplen 99.99% de Python2.6, y es más rápido que CPython (el intérprete de Python hecho en C).

También se habló mucho alrededor de Python 3 siendo el futuro evidente... ya nadie se pregunta "cómo" ni "si pasará", sino "cuando se hará el click" y "quienes se están quedando atrás".

Python cumplió veinte años, y está más vivo que nunca.


Junin, pasado y futuro

Python — Lunes 10 de Enero de 2011, 23:38

Les dejo los videos de las Sextas Jornadas de Software Libre de Junín; acá están todos, y si releen mi post sobre el evento, pueden sacar cuales me gustaron, :)

Eso con respecto al pasado... ¿y al futuro?

Bueno, resulta que en Junín se realizará la tercera edición de PyCon Argentina (organizada por la misma gente que hizo las jornadas mencionadas arriba). PyConAr 2011 será en dicha ciudad los días Viernes 23 y Sábado 24 de Septiembre; una semana antes que PyCon Brasil.

Muchas lecturas aleatorias y secuenciales, ¿mmap?

Python — Viernes 03 de Diciembre de 2010, 20:22


Con Guillo y Alecu empezamos a charlar sobre si, en un módulo que estaba haciendo Guillo para el laburo convenía usar mmap al tener muchas lecturas secuenciales y muchas lecturas aletorias sobre un archivo grande. Obviamente, usando Python (¿faltaba aclararlo?).

Como no nos decidíamos, decidí medirlo.

Medimos!

Creé un archivo de cien millones de bytes al azar, y probé con distintos scripts hechos en el momento, con un comportamiento parecido al que iba a hacer Guillo:

  • Una lectura secuencial de todo el archivo, de a dos tamaños diferentes. En el script leo 50 bytes, y luego 450 bytes, y así; en la realidad se haría una lectura de ~50 bytes, longitud fija, y luego una de ~450, longitud variable.
  • Doscientas mil lecturas al azar en todo el archivo, siempre de 450 bytes. En la realidad, se harían muchas lecturas, de un valor no fijo pero precalculado.

En ambos casos, las pruebas que realicé fueron haciendo .read() y .seek() sobre archivos normales, haciendo .read() y .seek() sobre el mmap, y usando el mmap como un string, accediendo por slices.


Resultados

Entonces, lectura secuencial, leyendo los cien megabytes de principio a fin (en milisegundos):

- .read() y seek() sobre el file:  501 mseg
- .read() y seek() sobre el mmap:  492 mseg
- usando slices sobre el mmap:     169 mseg


Es notable la diferencia.

Hay que tener en cuenta que los primeros dos hacen dos llamadas a función por cada vuelta del loop (vean los archivos para más detalle), lo que suma 400 mil function calls en total. Yo había medido antes el costo de una llamada a función, y eran de un poco menos de 250 nanogundos: no parece mucho, pero en 400 mil llamadas, suman 100 milisegundos, lo que explica un poco la diferencia en lo medido.

En la lectura secuencial, tiempo total desde que se tiene la posición a leer hasta que se obtiene el string (en microsegundos):

- .read() y seek() sobre el file:  18.1 useg
- .read() y seek() sobre el mmap:  10.8 useg
- usando slices sobre el mmap:     10.3 useg



Conclusiones

Si vamos a usar mmap, en estos casos, conviene usar el acceso por slices (con corchetes).  

Tomando esos tiempos, mmap es un 296% más rápido en la lectura secuencial, y un 75% más rápido en el acceso aleatorio.

Claramente mmap es el ganador.


Disclaimers

Uno: Esto lo hice usando Python 2.6.6 en un Linux.

Dos: Mi disco es un SSD, seguramente en un disco con platos magnéticos la diferencia entre acceso secuencial y acceso aleatorio sea mayor.

Tres: Inmediatamente antes de hacer cada prueba, hay que decirle al sistema operativo que descarte los caches del filesystem, para que esto no nos deforme las medidas. Eso lo hice con este script.


Sextas Jornadas de Software Libre en Junín

Python — Lunes 08 de Noviembre de 2010, 20:23

El finde pasado estuve también de conferencia, en dichas jornadas.

Fuimos en mi auto Luciano, Roberto, Fisa y yo. Arrancamos el viernes tempranito y a eso de las dos de la tarde ya estábamos allá, donde fuimos muy bien recibidos. Hicimos el check in, almorzamos, y luego hicimos algo de tiempo (yo hice una micro siesta y me pegué un baño) y finalmente cruzamos la calle hasta la Universidad, donde arrancó el evento.

Yo abrí la conferencia con la charla de Python más rápido que C y luego hubieron algunas más que ya había visto, y una de "Fortificacion en instalaciones de servidores Debian" por Luciano Bello, que estuvo muy bien, super interesante.

Esa fue la última charla del día (que como había arrancado a la tarde, terminó a las nueve de la noche), así que luego de un rato en el que pasamos apenas por el hotel, nos fuimos a un asado los organizadores y disertantes (los que estábamos allí y un par que cayeron más tarde). El asado estuvo genial, todo muy rico (picada, asado y postres), y el ambiente copadísimo. Hace rato que no me reía tanto en una reunión así.

Ya pasada medianoche emprendimos el regreso caminando (eran unas quince cuadras hasta el hotel), pero media cuadra antes de llegar al mismo vimos un pool abierto, y la tentación fue muy grande: con Nico César nos quedamos como tres horas más jugando y charlando.

Al otro día obviamente me levanté más tarde de lo que hubiese debido, me afeité, bañé, desayuné y llegué a la Universidad para la segunda charla. El segundo día también estuvo interesante, destaco las charlas de Andrés Riancho sobre aspectos de seguridad web, la de Nico César sobre administración de sistemas en gran cantidad de servidores, y otra de Luciano Bello sobre Linux capabilities.

La última charla del evento fue Entendiendo Unicode, luego algunas palabras de los organizadores, un sorteo, fotos, y desbande generalizado.

Con algunos de los chicos nos fuimos a tomar una cerveza, y luego hicimos un rato de tiempo hasta que fuimos a comer, a un club local. Luego al hotel, a dormir tempranito, porque el domingo arrancábamos el viaje de regreso a las ocho y media de la mañana...

La verdad es que la pasé genial el fin de semana. No sólo porque el evento en sí estuvo bárbaro (casi todas las charlas me resultaron interesantes, y estuvo bien organizado), sino que me volví a ver a un grupo de gente con el que me llevo muy bien. Es notable la dinámica que se logra en estas conferencias, porque hay un montón de gente de todo el país que si no fuese por estos eventos no nos veríamos (¡ni nos hubiésemos conocido!) y nos vamos reencontrando algunas veces al año en distintos puntos de nuestra geografía.

Es un lujo poder participar en esto.

Conferencias Python Cono Sur 2010

Python — Jueves 28 de Octubre de 2010, 09:00

Una atrás de la otra, pasaron más rápido de lo que hubiese querido.

En Córdoba estuve un par de días antes de la conferencia http://ar.pycon.org/, incluso un día trabajando desde allá (el otro ayudando un poco). Pero igual me fui con la sensación de que me faltó charlar con un montón de gente. Quizás estoy mal acostumbrado por los PyCamp, donde son cuatro días no tan estructurados como en una conferencia, y uno puede lograr un mayor contacto humano.

Como conté, dí dos charlas, las cuales salieron bien. Las Charlas Relámpago estuvieron geniales, los keynotes no tanto. Los dos días luego de la conferencia estuvieron buenos (el viernes hubo un asado que no fue asado, lejos de la ciudad, y el sábado una cerveceada, en un bar copado a unas cuadras de la Uni).

Cerveceada cordobesa

¿Cómo es un asado que no es asado? Originalmente iba a ser asado, pero terminó siendo algo que parece estar muy de moda en Córdoba: "pata". Con el término "pata" se refieren a que uno contrata el servicio de una gente que vienen con una pata graaande de ternera, ya cocida, calentita, mucho pan, algunos tarritos con diferentes salsitas, y la cortan ahí "en vivo", y uno mismo se va haciendo sanguchitos. No me quedó claro si el tomate y la lechuga que había la habían puesto los organizadores, o vienen incluidos en el servicio de "pata".

Todas mis fotos de PyCon en Córdoba, acá. Y acá están las de Marcos Dione, fotógrafo (semi?) oficial del evento.

PyCon Brasil fue mucho más express. Como mi keynote fue decidida medio de emergencia, mi vuelo fue medio "como pude". Viajé a Curitiba el jueves a la mañana, vía Montevideo (buenísimo, porque salí de Aeroparque), y llegué allá a media tarde, perdiéndome casi todo el primer día de la conferencia. Una cal y una de arena con respecto al vuelo de Pluna: no te sirven nada a bordo a menos que lo compres, pero los aviones (Bombardier CRJ-900NG) son realmente cómodos.

Me pasaron a buscar por el aeropuerto, me llevaron hasta al hotel donde hice el check-in y dejé algunas cosas, y fuimos a la conferencia. Llegué más o menos justo para las Lightning Talks, y me quedé en la Asamblea de la Asociación de Python Brasil, donde casi no entendí nada de lo que discutían. Casi. Luego, fuimos todos a cenar a una especie de tenedor libre en la que pasean un montón de mozos con distintos cortes de carne y te van sirviendo. Comí muy bien, luego me llevaron hasta el hotel, y al sobre.

Al otro día me levanté no demasiado temprano, desayuné tranqui y me tomé un taxi hasta la Universidad. Estuve un rato con la gente, hasta que a las once y cuarto arrancó una charla donde contaban qué es Arduino, cómo se conecta, un ejemplo de programita en C, y luego cómo usarlo desde Python a través de Firmata.

Luego del almuerzo (algo bien brasileño en un lugar cercano), vino mi keynote. Mi charla sobre Comunidad, anarquía y subversión salió muy bien, pude hilar todos los conceptos que quería, y hacer el remate con el efecto deseado sin que parezca tirado de los pelos. Tuve muy buen feedback, no sólo por algunas preguntas en el momento, sino gente que luego se me acercó. "Motivadora" fue un adjetivo que me gustó.

Luego hubieron un par de charlas más, y llegaron las charlas relámpagos. Yo dí una de las charlitas: Archivos ejecutables de Python, una pequeña receta que ya pondré acá como post, tomada de una charla más larga de John Lenton. Ni bien terminaron me llamé un taxi, y me volví al hotel. Compré algo para comer, y a dormir temprano, que estaba destruido...

PyCon Brasil

El sábado todo fue más tranquilo, yo me desperté tarde, llegué a media mañana, pero vi bastante gente que llegó más tarde que yo. Como había desayunado tarde terminé no almorzando, sino que paseando un poquito por ahí. Presencié la keynote de Ruby, y estuve en un par más pero sin prestar atención casi. Al final del día, volví a presentar una Charla Rápida, esta vez sobre PET (Python Entre Todos, la revista de PyAr), cuya primer edición está siendo traducida al portugués en este momento (ya está en castellano e inglés).

A la noche, fuimos a comer a un lugar de comida árabe. No estaba demasiado ambientado, ni nada, pero era árabe posta (o sea, no era "árabe para turistas", sino "árabe para árabes"). Comí muchas cosas raras. Incluso algunas que al principio no me animé, como carne cruda condimentada (pero no cocinada con limón, por ejemplo...).

El domingo me levanté temprano, y me llevaron a pasear a una feria artesanal, luego a almorzar, y finalmente me alcanzaron hasta el aeropuerto (gracias Ramiro!). El viaje de vuelta todo muy bien, y finalmente pude llegar a casa. Todas las fotos de PyCon Br, acá.

Powered by LifeType