Python y (mp3info) ID3V2


Siguiendo con la ardua tarea de modificar los metatags de mp3 para que al meterlos al aipo no me creen una denegación de servicio por hueva.

Como estoy metiendo un par de colecciones que usan múltiples artistas, pues como que no es agradable que ahora las listas categorizadas por artista o por disco tengan en vez de unas 20 entradas, como 200, en 200 artistas o discos es prácticamente imposible encontrar rápidamente lo que a uno se le antoja oír.

Pero resulta ser que por alguna sospechoza razón el gtkpod prefiere los tags ID3v2 que los ID3v1, y pues resulta que el modulito de perl no sabe escribir correctamente los de la versión 2, así que rápidamente dí un googlaso a un modulo similar en python, y taraaaaaaaaaaaaan, así me quedó el script en python

from mutagen.easyid3 import EasyID3                                                                                         
from string import strip
import re

file = open("tt.txt")
for line in file:
line = line[:-1]
ch = EasyID3(line)
p = re.compile('\(|\)')
line = p.sub('-', line)
p = re.compile(r'\-')
x = p.split(line)
n = strip(x[0])
a = strip(x[1])
t = strip(x[2])
y = strip(x[3])
ch["title"] = a + " - " + t
ch["album"] = "100 Gratest Dance Hits of the 90's"
ch["artist"] = "100 Gratest Dance Hits of the 90's"
ch["tracknumber"] = n
ch["date"] = y
ch["genre"] = "Pop"
ch.save()

Unas cuantas líneas ahorradas porque en python existe strip, que hace el trim “bilateral”.

mmmm, pos ta chido, me pregunto cuando voy a pasar de escribir cosas de menos de 100 lineas a hacer algo que realmente valga la pena.



django: Todo hecho fácil


Django es la neta del planeta para mi 🙂

Lo conocí gracias a un comentario del “buena voz mother fucker” hace unos meses, y como python es mi lenguaje favorito cuando se trata de aprender algo nuevo, pues inmediatamente me puse a checar ese nuevo “framework” y en cuestión de horas estaba totalmente enamorado :P.

Cuando se trata de programar en Python, simplemente no soy bueno, durante un par de años he hecho cosas sencillas, incluso con Glade y GTK, y recuerdo cuando estaba en tmz que me avente un “servidor de chat” muy simple, que tiempos aquellos, pero simplemente no soy muy productivo escribiendo Python, así que a veces me toma muchas horas hacer algo sencillo, de hecho luego sacando cuentas el numero de lineas por hora que escribo llega a ser muy cercano a 1 !! pero siempre quedo contento porque a pesar de terminar con muy pocas lineas, siempre logro tener algo que, al menos para mi, se ve muy elegante, y hace exactamente lo que quiero.

Y volviendo a Django, simplemente es asombroso lo que se puede hacer con tan poco conocimiento, voy a exponer unas cuantas lineas de un sistema pqueño que estoy haciendo para guardar datos de usuarios en la red, es realmente simple, pero preferí hacerlo en Python/Django que en PHP que es mi lenguaje más productivo en general (para web casi exclusivamente), y la razón de la elección fué que Django me permite hacer trivialmente varias tareas: autenticación, localización (traducción), separación MVC (al estilo Django, pero muy elegante), portabilidad en la base de datos, uso de plantillas, URL bonitos, y como dicen en su sitio, “no me repito”, o sea, las cosas se hacen de la mejor manera para que sea trivial reproducirlas cuantas veces sea necesario sin mucho código (one-liners seria la “palabra correcta”), y además de todo me crea un panel de control en el que puedo editar datos a placer.

Como antecedente, me tomo unas 4 a 6 horas hacer lo que voy a escribir aqui, y este es el resumen de programación:
Lineas Archivo (wc -l)
10 urls.py
37 base/models.py
8 base/urls.py
40 base/views.py
95 total

en las plantillas tengo mas de 130 lineas, pero pues ni vale la pena contar eso porque el gaste de HTML puede ser arbitrario, depende de cuando diseño le quieras meter, y que tan hábil seas para hacerlo de manera elegante.

En realidad esta no es la aplicación terminada, solo hice un ejemplo que necesito para reproducirlo para todas las tablas que sean necesarias, este ejemplo es un listado paginado, con soporte de todo lo que dije arriba.

No quiero irme sobre todos los detalles de la configuración (settings.py) de la aplicación, simplemente voy a remitirme a la parte del listado paginado.

en una “sub aplicación” de la aplicación principal tengo este url.py:


from django.conf.urls.defaults import *
from iplist.base import models, views

urlpatterns = patterns('',
(r'^$', 'iplist.base.views.myview'),
(r'^view/$', views.object_list, {'model': models.People}),
)

Lo que hace es definir 2 listados parecidos, el segundo por medio de las vistas genéricas que proporciona Django (generic.views), ambos paginan, pero el segundo es realmente elegante y portable, mientras que el primero es una vista a una sola tabla en particular.

Este es el archivo view.py, que contiene las 2 vistas en cuestion:


from django.template import Context, loader
from django.contrib.auth.decorators import login_required
from iplist.base.models import People
from django.core.paginator import ObjectPaginator, InvalidPage

from django.http import HttpResponse, HttpResponseRedirect
from django.views.generic import list_detail

@login_required
def myview(request):
people_list = ObjectPaginator(People.objects.all().order_by('name'), 3)
t = loader.get_template('base/list.html')
try:
page = int(request.GET.get('page'));
except:
page = 0
print page, people_list.pages
if (page < people_list.pages ):
c = Context({
'people_list': people_list.get_page(page),
'page': page,
'has_next': people_list.has_next_page(page),
'has_prev': people_list.has_previous_page(page),
'next_page': page+1 ,
'prev_page': page-1 ,
'paginator': people_list,
})
return HttpResponse(t.render(c))
else:
return HttpResponseRedirect('/list/')

@login_required
def object_list(request, model):
try:
return list_detail.object_list(
request,
queryset = model.objects.all().order_by('name'),
template_name = 'base/%s_list.html' % model.__name__.lower(),
paginate_by = 3,
)
except:
return HttpResponseRedirect('/list/view')

Las primeras lineas de “import” son necesarias para la vista de la tabla People paginada, los ultimos 2 “import”s son los que se necesitan para la vista genérica, de hecho el último contiene 2 funciones necesaria para la primera vista, y otra para la segunda, y la linea que importa login_required se usa en los 2 (5 contra 3 imports!).

En la primera vista usamos la herramienta de paginación de Django, y seleccionamos una tabla sobre la cual vamos a iterar en la plantilla, después tenemos que tomar la plantilla y alimentarla con los datos necesarios. Aquí un detalle importante, las plantillas no pueden accesar a métodos, solo accesan valores, arreglos, etc, por lo que es necesario alimentar bastante, en ves de por ejemplo pasar el objeto people_list con todas sus capacidades.

La segunda vista/clase/funcion/como-quieras-llamarle toma el parametro “page” automáticamente de GET, pagina, y manda los parámetros relevantes a la plantilla (pagina proxima, numero total de paginas, de registros, etc) con solo agregar “paginate_by” a la funcion list_detail.object_list.

NOTA: la linea precediendo a cada función hace necesario estar logueado con un usuario para ver la vista, las tablas y sistema de autenticacion los creo Django por mi, si quieres tener una forma de logueo solo creas una plantilla básica y agregas una linea a url.py y listo ! todo lo demás Django lo hace sin ayuda 🙂

De tal manera que esta plantilla (templates/base/people_list.html) hace todo lo que se esperaría de una lista paginada:


{% load i18n %}
{% extends "base.html" %}

{% block title %}{% trans "Generic List" %}{% endblock %}

{% block content %}
{% for entry in object_list %}
<div style="border:1px solid black;">
<h1>{{ entry.name }}</h1>
<p>{{ entry.comments }} ({{ entry.department }})</p>
</div>
{% endfor %}
{% if has_previous %}
<a href="?page={{ previous }}">&lt;</a>
{% else %}
{% trans "No Previous Page" %}
{% endif %}
|
{% if has_next %}
<a href="?page={{ next }}">&gt;</a>
{% else %}
{%trans "No More Pages" %}
{% endif %}
<br />
{% endblock %}

a través del segundo patrón en el url.py que puse arriba, y si notan todos los textos están marcados para traducción (notar la primera linea, es importante que sea así), pero para no hacer el cuento muy largo eso lo dejo para otro post (si es que lo llego a hacer :P).

Y dejo aquí la plantilla de la vista “no genérica”:


{% load i18n %}

{% extends "base.html" %}

{% block title %}{% trans "Another Testing Template" %}{% endblock %}

{% block content %}
{% for entry in people_list %}
<div style="border='1px';">
<h2>{{ entry.name }}</h2>
<p>{{ entry.comments }}</p>
</div>
{% endfor %}
{% if has_prev %}
<a href="?page={{ prev_page }}">&lt;</a>
{% else %}
{% trans "No Previous Page" %}
{% endif %}
|
{% if has_next %}
<a href="?page={{ next_page }}">&gt;</a>
{% else %}
{%trans "No More Pages" %}
{% endif %}
{% endblock %}

En conclusión, podemos lograr en 11 lineas de programación tener una función que nos pagina, y protege con autenticación el listado de cualquier tabla, ya que el nombre de la tabla lo mandamos a través de un parámetro en una linea de url.py, de tal manera que podemos hacer cuantos querramos y reutilizar la misma vista, y al final solo tenemos que crear plantillas personalizadas para cada vista, ya que cada tabla tienen campos diferentes, o no ?? 🙂

O en otras palabras, copias una linea en url.py, le cambias lo esencial, y copias la plantilla y haces lo mismo, igual y quieres un diseño totalmente diferente para cada listado :), y es todo, volvemos aún mas aburrido el trabajo del desarrollador web ! y le ahorramos un buen de tiempo, ni siquiera tiene que aprender struts !!

Hasta la proxima

P.D. Notaron la elegancia de la validación para page ?? es o no bonito Python ??