28 de Julio, 2010

Diferencias cambiando de Perl a Python

Seguro que hay más diferencias, y ya las iré encontrando, pero la primera que realmente no me gusta es en el soporte de bases de datos.

Estoy programando una herramienta sencilla para hacer informes desde SQL a CSV (bueno, y más cosas... pero eso es lo principal: ysimplereports), y es la primera vez que accedo a una base de datos SQL desde Python (no, mis aventuras con Redis no cuentan, es un API específico).

La situación en Perl es la siguiente:

  1. Instalas DBI, que es el interfaz de Perl para bases de datos.
  2. Instalas el driver que toque, de todos los que hay, según lo que necesites.
  3. No hay paso 3.

Además, si tienes instalado perldoc (versión online), ya tienes la documentación, muy clara y con ejemplos, a la que puedes acceder incluso vía man.

En el caso de Python, la cosa es diferente. Después de andar algo perdido, pregunté en identi.ca (genial, el grupo de Python es realmente útil), porque tenía la impresión de que se me escapaba algo, y me apuntaron a el wiki de Python sobre programación de bases de datos.

En ese wiki hay un PEP (Python Enhancement Proposal), donde se enlaza el PEP 249, que define la especificación 2.0 para el API de bases de datos de Python.

En este punto, los pasos son:

  1. Buscar un módulo para la base de datos que quiero utilizar que implemente el mencionado PEP. Hay una lista de interfaces en el wiki.
  2. Instalarlo el módulo, y buscar la documentación, porque el PEP es general y no entra en detalles específicos (por ejemplo, parámetros de conexión).
  3. No debería haber paso 3.

Me comentan que el caso del módulo MySQLdb para MySQL es el que anda más flojo respecto a la documentación, pero la verdad es que he ojeado con pydoc en local, y me ha decepcionado bastante.

No es que no hayan ejemplos (que no los hay), sino que leer en la descripción algo como:

connect() -- connects to server

See the C API specification and the MySQL documentation for more info on other items.

Y más abajo, en funciones, algo como:

Connect(*args, **kwargs)
        Factory function for connections.Connection.

Digamos que da mala sensación :o.

En la web del proyecto, el módulo sí está documentado bastante bien (MySQLdb User's Guide), pero igual la alta calidad de la documentación de DBI (¡y no tener que acceder a una web!) me tiene mal acostumbrado.

Quizás la idea centralizada de DBI permite tener mayores controles de calidad, y además dé mayor sensación de cohexión, o igual es simplemente que, como me comentan, MySQLdb es el módulo más flojo en cuando a documentación vía pydoc.

No es algo fatal, pero siendo totalmente extraño a cómo funciona Python, el soporte de base de datos definitivamente no me termina de convencer :/.

Anotación por Juan J. Martínez, clasificada en: perl, python.

Hay 2 comentarios

Gravatar

Pues en Perl yo me quedaría con DBIx::Class. Ha hecho que no quiera volver a escribir SQL en mi codigo :)

Saludos!

por quelcom, en 2010-07-28 21:40:08

Gravatar

Yo prefiero Class::DBI ;)

Pero fíjate que eso es un ORM, y que por debajo sigue usando DBI.

No es exáctamente de lo que hablo. En Python también hay buenos ORM, como SQLAlchemy

por Juanjo, en 2010-07-28 21:51:45

Los comentarios están cerrados: los comentarios se cierran automáticamente una vez pasados 30 días. Si quieres comentar algo acerca de la anotación, puedes hacerlo por e-mail.

Algunas anotaciones relacionadas: