Archivo

Archivo para la categoría ‘python’

Desensamblando Python

domingo, 30 de agosto de 2009 Sin comentarios

Mucho no me gusta hacer posts con casi nada de aporte propio, pero en este caso se lo merece. Este post sólo va a referenciar al excelente sitio de Doug Hellman, PyMOTW (Python Module of the Week). Básicamente el autor presenta una vez por semana un módulo de la biblioteca estándar de Python, realizando un análisis del mismo y mostrando ejemplos de uso.

En particular, esta semana hizo una introducción al módulo dis, que desensambla código Python mostrando el bytecode respectivo. Lo bueno es que muestra varios usos para el mismo (nuevos para mí), como en el caso de un debug o en el de optimizar el funcionamiento ahorrando bytecodes.

En fin, preparándome para la inminente PyCon Argentina, me entusiasmé leyendo y probando los ejemplos de este post. No puede haber programador python que no esté subscripto a su feed. 🙂

Saludos!

Categories: codear, programación, python, ubuntu-ar Tags:

PyCon Argentina 2009: Abierta la Inscripción

viernes, 14 de agosto de 2009 Sin comentarios

Sólo me voy a limitar a copiar el texto de la invitación… de más está decir que espero ansioso los días para ir, y creo que va a estar buenísima. Si sos programador o estás haciendo tus primeras armas en la programación, ¡no podés faltar!

PyConAR-2009-banner-grande

Está abierta la inscripción para participar de PyCon Argentina 2009, la primera conferencia en castellano sobre el lenguaje de programación Python, a realizarse los días 4 y 5 de septiembre en la sede de la Universidad de Belgrano, Zabala 1837, en la Ciudad de Buenos Aires.

En esta primera edición contaremos con la participación de Jacob Kaplan-Moss (creador de Django) y Collin Winter (core developer de Python) como invitados especiales del evento, y con más de 30 charlas sobre Python y temas relacionados, desde tutoriales para principiantes hasta charlas de nivel avanzado.

Cronograma de charlas:
http://ar.pycon.org/2009/conference/schedule/

La entrada es libre y gratuita. Para evitar contratiempos, confirmar su asistencia y recibir credencial y demás materiales de la conferencia, se recomienda realizar inscripción previa en el sitio web.

Inscripción y más información:
http://ar.pycon.org/2009/registration/

Espero conocer gente ahí… ¡nos vemos!

Categories: codear, python, ubuntu-ar Tags:

Control de Versiones: Manejando las diferencias entre distribuido y centralizado

sábado, 25 de julio de 2009 Sin comentarios

VCSsDando vueltas por ahí, me entero que es muy sencillo utilizar localmente versionado de código fuente (gracias a los sistemas de control de versiones distribuidos, como por ejemplo Mercurial, GIT y Bazaar) para luego subir/actualizar los cambios a un repositorio Subversion principal. Es decir, en vez de usar los comandos svn como clientes de un servidor Subversion, es posible utilizar alguno de estos sistemas distribuidos como clientes «consumidores» del repositorio principal, para luego aprovechar sus importantes ventajas en forma local.

En principio, admito que no conozco ningún VCS distribuido, más que nada por vagancia (je), pero esto en particular sí lo necesito de vez en cuando, principalmente cuando no estoy conectado, y/o cuando los cambios que hago con respecto a trunk son profundos, llevan tiempo y quiero tener un control más «fino» en lo que hago.

A ver, habiendo nombrado primero los sistemas más conocidos (por mí), se desprende que tenemos:

  • Logo MercurialMercurial-Svn: Si bien el autor del artículo que me inspiró a escribir esto (Vadim Zeitlin, desarrollador de wxWidgets) comentaba que le gusta muchísimo Mercurial por su fácil uso, al momento de probar esta extensión para subir los cambios al servidor SVN de wxWidgets tuvo problemas de performance, uso de memoria, etc. De todas maneras, el código fuente en el repositorio de wxWidgets es bastante grandote (~330MB), así que quizás funcione bien para proyectos chicos/medianos, y más si uno ya conoce Mercurial.
  • Git-Svn: Bueno, citando nuevamente a Vadim, parece que critica un poco lo complicado de los comandos Git, sin embargo termina recomendándolo en forma rotunda por su velocidad y poca utilización de espacio extra en el disco*. Acá parece haber un tutorial cortito para utilizarlo (Google me devuelve muchísimos enlaces más por si es poco).

Git Version Control

En fin, recién me sumerjo en la lectura y experimentación de todo esto, pero para aquellos que trabajan contra un servidor SVN** y suben sus cambios con poca frecuencia al repositorio principal, «rompiendo todo» cada vez que lo hacen (guiño, guiño), me parece que esto les viene perfecto.

BazaarAdemás, tengo entendido que no es difícil usar Bazaar (por poner uno de ejemplo), y realmente está muy cool poder volver atrás en los cambios que uno hizo desde que hizo el checkout/update del SVN, mientras desarrolla, y sin tener que conectarse a Internet (VPN/SSH/etc.).

(*) Cuando el cliente de control de versiones distribuido hace un checkout del repositorio Subversion, no sólo descarga la última versión de trunk, sino que descarga todas las versiones pasadas de todas las ramas existentes, con lo cual el consumo de espacio en disco local pasa a ser un asunto importante. Git, según Vadim, parece tener poco overhead en este sentido comparado con la extensión de Mercurial.

(**) Una de las cuestiones que no le hacen perder valor e importancia a SVN es que, al ser centralizado, sigue siendo relevante en empresas que quieren tener un control más o menos estricto de su código; por lo tanto, la migración a sistemas distribuidos no siempre estará bajo su radar. Es por eso que hablo de «diferencias» en el título del post y no de una «futura migración», es decir, que los distribuidos sean los «nuevos vecinos de la cuadra» no quiere decir que vengan a reemplazar a los viejos y conocidos. 🙂

¡Saludos!

Categories: codear, programación, python, ubuntu-ar Tags:

¡Hola Mundo!

domingo, 24 de mayo de 2009 Sin comentarios

Bueno, este es el primer post de mi blog sobre WordPress en dominio propio, marcelofernandez.info.

No hace falta cambiar el Feed RSS, ya que al hacerlo yo en FeedBurner, directamente va a levantar los nuevos posts del dominio nuevo.

El cambio lo hice estrictamente porque me cansé de esperar que Blogger avance… es demasiado básico para un montón de cosas. Vamos a ver cómo nos va, por ahora me enamoré de WordPress. 🙂

Saludos

Categories: codear, misceláneos, python, ubuntu-ar Tags:

Renderizando PDFs en Python con Poppler

sábado, 2 de mayo de 2009 3 comentarios

Buenas… hoy voy a mostrar una forma de renderizar archivos PDF dentro de nuestras aplicaciones y desde Python, para casi cualquier plataforma con la estemos trabajando.

Introducción
Si bien cuando se arma una aplicación de escritorio se suele «llamar» a un software externo (Acrobat Reader, Fox-It, Evince, etc.) para que muestre el contenido de un archivo PDF, generalmente queda «feo»; nuestro programa pierde la interacción y el control de lo que el usuario hace con el mismo, implica superponer un programa arriba del otro, etc. Esto suele producir una experiencia dificultosa para el usuario de nuestro querido programa, y como corresponde, los programadores nos ponemos tristes. 🙁

Como una alternativa tenemos, en plataformas Windows, y estando el Acrobat Reader instalado previamente, la posibilidad de embeber en nuestro programa el mismo como un control ActiveX (hay otras alternativas) pero en el resto de las plataformas este problema no tenía solución (que yo conociera, al menos), ni siquiera algo más «liviano». El resultado de embeber todo el Acrobat Reader es más o menos lo que hacen los navegadores web cuando tienen el plugin de Adobe instalado y hacemos click en un link a un archivo PDF de la web:

(Después de 1 minuto, y si el usuario no cerró la ventana, aparece esto)

Hace unos días, en la lista de usuarios de las bibliotecas wxPython preguntaron si se podía renderizar un PDF dentro de una ventana del mismo programa, pero sobre Linux, y buscando la solución me encontré con un binding Python para Poppler.

Solución: Poppler-Python sobre Cairo
Veamos, Poppler es una biblioteca de código abierto desarrollada en C con el objetivo de renderizar (es decir, interpretar y dibujar) archivos PDF, siendo la evolución del viejo Xpdf. Es una pieza de software imprescindible en el escritorio de cualquier Sistema Operativo Libre, ya que es un trabajo bárbaro el que hace, y además es la piedra fundamental de programas como Evince y Okular (más allá de que el PDF es un formato de archivo universal). Y lo mejor es que dibuja sobre cualquier contexto de dibujo de Cairo, así que donde haya Cairo y compilador de C, puede estar Poppler*.

Hasta acá, bien, Poppler se puede utilizar desde C (como lo hace Evince, el visor de PDFs de Gnome). Pero ‘ete aquí que me encontré con estos bindings de Poppler para Python, y si bien el ejemplo que éstos incluyen utiliza PyGTK, en realidad, sólo necesita de un Canvas Cairo (GTK dibuja mucho sobre Cairo y provee mecanismos para que el desarrollador lo utilice también); es el mismo Cairo que incluye wxPython a partir de la versión 2.8.9.0 (aunque se puede utilizar con ctypes desde versiones anteriores a la 2.8.9).

Un poco de Código
En fin, voy a tratar de explicarlo mejor, esta es la manera de renderizar un PDF dentro de una aplicación PyGTK. Voy a pegar acá abajo lo relevante:

    def __init__(self):
        [...]
        self.document = poppler.document_new_from_file (uri, None)
        self.n_pages = self.document.get_n_pages()
        self.current_page = self.document.get_page(0)
        self.scale = 1
        self.width, self.height = self.current_page.get_size()
        [...]
        self.dwg = gtk.DrawingArea()
        self.dwg.set_size_request(int(self.width), int(self.height))
        self.dwg.connect("expose-event", self.on_expose)
 
[...]
 
    def on_expose(self, widget, event):
        cr = widget.window.cairo_create()
        cr.set_source_rgb(1, 1, 1)
 
        if self.scale != 1:
            cr.scale(self.scale, self.scale)
 
        cr.rectangle(0, 0, self.width, self.height)
        cr.fill()
        self.current_page.render(cr)

Como se puede ver, Poppler-Python se encarga de cargar el archivo, devolver la cantidad de páginas, etc., mientras que con GTK creamos el contexto de dibujo Cairo, y todo lo que hacemos es decirle a Poppler «dibujá acá, en este contexto Cairo».

Entonces me puse a jugar con wxPython para hacer lo mismo, !y funciona!

Acá está el ejemplo:

#!/usr/bin/env python
import wx
import wx.lib.wxcairo
import sys
import poppler
 
class MyFrame(wx.Frame):
 
    def __init__(self):
        wx.Frame.__init__(self, None, -1, "Cairo Test", size=(500,400))
        self.Bind(wx.EVT_PAINT, self.OnPaint)
        uri = "file://" + sys.argv[1]
        self.document = poppler.document_new_from_file (uri, None)
        self.n_pages = self.document.get_n_pages()
 
        self.current_page = self.document.get_page(0)
        self.scale = 1
        self.width, self.height = self.current_page.get_size()
        self.SetSize((self.width, self.height))
 
    def OnPaint(self, event):
        dc = wx.PaintDC(self)
        cr = wx.lib.wxcairo.ContextFromDC(dc)
        cr.set_source_rgb(1, 1, 1)
 
        if self.scale != 1:
            cr.scale(self.scale, self.scale)
 
        cr.rectangle(0, 0, self.width, self.height)
        cr.fill()
        self.current_page.render(cr)
 
if __name__=="__main__":
    app = wx.App()
    f = MyFrame()
    f.Show()
    app.MainLoop()

Y acá está la captura de pantalla obligada, luego de ejecutar «python ejemplo.py /path/al/archivo.pdf» (click para agrandar):

De esta manera, es posible utilizar Python, Poppler y wxPython (o PyGTK) para mostrar y manejar el contenido de un archivo PDF dentro de nuestra aplicación y en casi cualquier plataforma, sin recurrir a componentes de terceros. 🙂

Consideraciones:
Bueno, quisiera comentar que poppler-python parece ser un proyecto «joven», ya que todavía sólo está incluido en los repositorios de Ubuntu 9.04 en adelante. Con lo cual, en caso de utilizarlo en otras distribuciones y/o plataformas, hay que hacer un checkout desde sus repositorios y compilarlo; sus únicas dependencias son pycairo y poppler (0.10.x o posterior). Es muy sencillo hacerlo (el típico ./configure, make y make install), y no tuve ningún problema, utilizando Ubuntu 8.10.

En caso de querer utilizar Poppler-Python sobre el Cairo que incluye wxPython, lo mejor es utilizar una versión 2.8.9.x o superior de wxPython (ya con eso es suficiente, porque incluye Cairo en el paquete). Ubuntu 9.04 trae wxPython 2.8.9.1, Poppler 0.10.x y Poppler-Python en los repositorios, así que con un único apt-get ya tenemos todo lo necesario para hacer andar el ejemplo de arriba.

En mi caso, para probarlo en Ubuntu 8.10, tuve que compilar poppler desde los fuentes (traía la versión 0.8.x) y después compilar python-poppler, por un lado. Por el otro, para utilizar Cairo sobre wxPython 2.8.8.0 (el que viene en Ubuntu 8.10), llamé a Cairo con ctypes, como dice acá, y me quedó este ejemplo. Este procedimiento sería similar para cualquier otra distribución con versiones viejas de Poppler y/o de wxPython. Para la distribución de nuestro software todo se simplifica, ya que se puede usar tranquilamente Py2Exe, cx_Freeze o PyInstaller, por nombrar algunos. Pero eso es tema de otro post 😉

* Poppler denomina Frontend a las diferentes APIs que tiene para ser utilizado, entre ellas QT4 (base de KDE) y Glib (GTK principalmente, base de Gnome). Y tiene como backend (es decir, necesita para dibujar) no sólo a Cairo, sino que también puede dibujar sobre Splash (ignoro qué es, y Google no me devuelve nada relevante).

Bueno, espero que al menos le sirva a alguien, que lo aprovechen y lo mejoren!

Saludos
Marcelo

Categories: codear, linux, programación, python Tags: