El Ornitorrinco Enmascarado

Django: Actualizar un contador en un modelo

2023-04-29T13:20:00.003+01:00

Actualizar un contador en un modelo en Django

A veces necesitamos realizar algún tipo de operación aritmética sencilla en el modelo, y queremos que persista en la base de datos. Un ejemplo común es un contador, que queremos incrementar o decrementar en determinadas circunstancias.

Una solución sencilla sería hacerlo directamente en Python, algo como esto:

product = Item.objects.get(pk=4523)
product.stock += 1
product.save()

Funciona perfecto, pero tiene dos problemas: Uno es una posible condición de carrera, si tenemos la mala suerte de que otro proceso está cambiando el valor del contador stock justo durante el intervalo entre que hemos leído los datos de la base de datos y el momento es que volvemos a salvarlos.

El segundo problema es otro aspecto del mismo, estamos haciendo dos consultas a la base de datos, una para obtener el valor antiguo y otra para guardar el valor nuevo.

Podemos resolver ambos problemas (Ya que los dos tienen la misma base) con un único paso, que realizará de forma atómica la propia base de datos, usando lo que Django llama expresiones F. Las expresiones F nos permiten realizar una actualización de un campo con valores relativos otros campos de la tabla.

Para el ejemplo anterior, la solución mejorada podría ser:

from django.db.models import F

product = Item.objects.get(pk=4523)
Item.stock = F("stock”) + 1
product.save(update_fields=['stock'])

El resultado sería una única interacción con la base de datos, que ejecutaría un código SQL similar al siguiente :

UPDATE Item
   SET stock = stock + 1
 WHERE id = 4523;

The return of the Masked Platyplus

2020-10-15T00:16:00.002+01:00

Dos añitos sin publicar nada... Igual debería retomar esto

Cristina Cifuentes roba en un supermercado, ahora con banda sonora

2018-04-25T11:17:00.001+01:00

Cómo determinar si un archivo es una imagen PNG

2018-03-19T09:48:00.000+00:00

Los primeros 8 bytes de un fichero PNG son siempre los mismos. En decimal, serían:

    137 80 78 71 13 10 26 10

Para poder examinar esos 8 bits en linux/unix, podemos usar la utilidad head, y con hexdump podemos verlos en hexadecimal

    head --bytes=8 ejemplo.jpg | hexdump -C

El resultado debería ser:

00000000  89 50 4e 47 0d 0a 1a 0a                           |.PNG....|
00000008

Buscar archivos PNG con otra extensión

El siguiente codigo en Python 3 localiza archivos de tipo PNG sin extensión o con una extensión que no sería la correcta:

    import os
    PNG_SIGNATURE = b'\x89\x50\x4e\x47\x0d\x0a\x1a\x0a'

    for (path, dirnames,filenames) in os.walk('/home/jileon'):
        for filename in filenames:
            full_name = os.path.join(path, filename)
            if os.access(full_name, os.R_OK):
                with open(full_name, 'rb') as f:
                    head = f.read(8)
                    if head == PNG_SIGNATURE:
                        if not full_name.lower().endswith('.png'):
                            print(full_name)

Uso del decorador functools.wraps en Python

2017-08-30T12:58:00.000+01:00

Supongamos una función muy sencilla, pero correctamente comentada:

def suma(a, b):
    '''Esta función acepta dos parámetros, y devuelve la suma de ellos.
    
    Ejemplo:
    
    >>> result = suma(2, 4)
    >>> assert result == 6
    '''
    return a + b

Vemos que funciona perfectamente:

suma(2,390)

Si pedimos información de la función con help, nos da la documentación que incluimos como docstring:

help(suma)

Help on function suma in module __main__:

suma(a, b)
    Esta función acepta dos parámetros, y devuelve la suma de ellos.
    
    Ejemplo:
    
    >>> result = suma(2, 4)
    >>> assert result == 6

Vamos ahora a decorarla con un decorador muy sencillo, simplemente escribe a consola cuando llamamos a la función y, después de ejecutarla, imprime también el resultado:

def log(functor):
    def wrapper(*args, **kwargs):
        print('Llamando a la función: {}'.format(functor.__name__))
        result = functor(*args, **kwargs)
        print('Resultado: {}'.format(result))
        return result
    return wrapper

@log
def suma(a, b):
    '''Esta función acepta dos parámetros, y devuelve la suma de ellos.
    
    Ejemplo:
    
    >>> result = suma(2, 4)
    >>> assert result == 6
    '''
    return a + b

Vemos que el decorador funciona correctamente:

suma(2,3)

Llamando a la función: suma
Resultado: 5

El problema es que la nueva función suma ha perdido todo los metadatos de la función original, entre ellos la documentación:

help(suma)
suma.__name__

Help on function wrapper in module __main__:

wrapper(*args, **kwargs)

'wrapper'

El decorador wraps del módulo functools lo que hace es resolver este problema, inyectando en la función decorada todos los metadatos de la función original, entre ellos la docstring (Por eso necesita como parámetro la función original).

import functools

def log(functor):
    
    @functools.wraps(functor)
    def wrapper(*args, **kwargs):
        print('Llamando a la función: {}'.format(functor.__name__))
        result = functor(*args, **kwargs)
        print('Resultado: {}'.format(result))
        return result
    return wrapper

@log
def suma(a, b):
    '''Esta función acepta dos parámetros, y devuelve la suma de ellos.
    
    Ejemplo:
    
    >>> result = suma(2, 4)
    >>> assert result == 6
    '''
    return a + b

Vemos que todo sigue funcionando igual...

suma(2,3)

Llamando a la función: suma
Resultado: 5

Pero la función help muestra la documentación de la función original...

help(suma)

Help on function suma in module __main__:

suma(a, b)
    Esta función acepta dos parámetros, y devuelve la suma de ellos.
    
    Ejemplo:
    
    >>> result = suma(2, 4)
    >>> assert result == 6

Escrito en colaboración con Enrique Cordobés Faura.

Ejemplo de uso de pyparsing

2017-08-09T11:46:00.000+01:00

Nota: La versión más actualizada de este documento está siempre en

https://github.com/euribates/Charla-DSL/blob/master/Ejemplo-uso-pyparsing.ipynb

Ejemplo de uso de pyparsing

Vamos a utilizar pyparsing para procesar un fichero csv. Para hacer las cosas más interesantes, supondremos que el formato de los ficheros es muy laxo; por ejemplo, podemos encontrarnos con lo siguiente:

Los campos de texto pueden venir entrecomillados o no

Los campos de tipo fecha pueden venir en dos formatos: YYYY-MM-DD o DD/MM/YYYY

Los campos de tipo booleano pueden venir con los valores `1`, `S`, `Y` o `True` para el valor lógico verdadero, y `0`, `N`, `F` y `False` para el valor lógico falso

Los números decimales pueden venir con una coma o con un punto como separador decimal.

La primera línea contiene los nombres de los campos, el resto los datos; en los dos casos se separa cada valor por el caracter `;`

Ejemplo de datos a procesar

Algo como esto:

Comentario;Activo;Fecha;Importe
Texto sin comillas porque yo lo valgo;Y;2017-08-08;4292.00
"Ahora si que pongo comillas";F;25/8/2014;3200.00
Ya ves, todo vale;True;1/1/1970;4532,02

Una gramatica para estos ficheros

La gramática podría ser algo así:

root -> header + lines
header -> \.+ # ignorar la linea 
lines -> line+
line -> text + sep + date + sep + bool + sep + cost
text -> '"' + literal + '"' | literal
date -> year + '-' + month + '-' + day | day + '/' + month + '/' + year
cost -> \d+[\.|,]\d{2}
bool -> '1' | 'S' | 'Y' | 'T' | 'True' | '0' | 'N' | 'F' | 'False'
year -> \d{4}
month -> 1|2|3|4|5|6|7|8|9|10|11|12
day -> \d{1,2}

Implementación con pyparsing

Las gramáticas pueden ser un poco intimidantes la primera vez que las ves. Lo bueno de pyparsing es que nos permite testear y modificar las distintas partes de la gramática como piezas sueltas. Así podemos crear el parser poco a poco, ensamblando las distinas piezas, con la confianza de que estas funcionan.

Parseando fechas

Por ejemplo, para las fechas, que pueden venir en dos formatos, tenemos el siguiente fragmento de la gramática (pasado a la sintaxis de pyparsing, y por tanto cambiando el orden, la regla inicial sería la última):

In [2]:

from pyparsing import Literal, Regex, oneOf, StringEnd, Group, ParseException
​
dash = Literal('-')
slash = Literal('/')
year = Regex('\d{4}')
month = Regex('\d{1,2}')
day = Regex('\d{1,2}')
date = year + dash + month + dash + day ^ day + slash + month + slash + year
# pyparsong sobrecarga el operador ^ para indicar alternancia

La clase Literal sirve para indicar una expresión o token literal, que queremos detectar durante la fase de parseo. Así, definimos dash y slash para detectar los literales - y /. La clase Regex nos permite definir tokens usando expresiones regulares. Estos objetos, así como el resto de los que veremos, derivan de la clase ParserElement de pyparsing, que sobrecarga varios operadores para poder expresar las reglas de la gramática. Así, la regla:

date -> year + '-' + month + '-' + day | day + '/' + month + '/' + year

Se puede expresar en Python con los operadores + y ^:

date = year + dash + month + dash + day ^ day + slash + month + slash + year

Aparte de cambios como el uso del operador ^, o la definición de los literales dash y slash, podemos ver que la gramática se mapea de forma casi directa a expresiones Python.

Veamos que tal funciona este mini-parser:

In [3]:

try:
    date.parseString('hola')
except ParseException:
    pass  # Ok, no es una fecha
​
print(date.parseString('25/8/2016'))
print(date.parseString('2017-12-08'))
​

['25', '/', '8', '/', '2016']
['2017', '-', '12', '-', '08']

pyparsing define su propia clase de excepciones para errores de Parseo, parseException. Si nuestro parser es muy complicado puede ser interesante usar esta misma excepción para indicar nuestros propios errores. Por ejemplo, ahora mismo aceptamos para el día cualquier combinación de dos dígitos, e igualmente para el mes:

In [4]:

print(date.parseString('99/88/2016'))  # opps, esto no debería valer, pero vale

['99', '/', '88', '/', '2016']

Más adelante veremos que podemos tratar estos casos y elevar errores explicativos que provoquen el fallo del parser.

Por ahora, poco más de lo que podríamos hacer simplemente con expresiones regulares.

Podemos realizar una pequeña mejora. Observemos un detalle de los separadores usados en el formato de fechas, definidos como dash y slash; en realidad, sus valores no nos interesan. Podemos calcular el valor de la fecha sin necesidad de saber que caracteres se usaron como separador. Estos elementos son necesarios para el parser, pero no tienen más utilidad.

Existe una clase en pyparsing llamada Suppress que funciona exactamente igual que Literal, pero que retira el token, de forma que nos evitamos procesarlo. Cambiemos la gramática para redefinir dash y slash usando Suppress en vez de Literal:

In [5]:

from pyparsing import Suppress
​
dash = Suppress('-')
slash = Suppress('/')
year = Regex('\d{4}')
month = Regex('\d{1,2}')
day = Regex('\d{1,2}')
date = year + dash + month + dash + day ^ day + slash + month + slash + year

In [6]:

print(date.parseString('23/9/2016'))  # bien, el separador desaparece

['23', '9', '2016']

No está mal, pero la mejora realmente interesante sería que nos devolviera algo más elaborado, un objeto de tipo fecha, objetos de tipo datetime.datetime, por ejemplo. Vamos a ello. Para eso, necesitamos usar las reglas de parseo.

Reglas de parseo

Podemos asociar acciones a las reglas de parseo (en este daso, date) para que se ejecuten cada vez qe se active la regla.

Vamos a asociar una función que no haga nada, solo imprimir un valor para ver que, efectivamente, se ejecuta cuando la regla de parseo se activa. Usaremos el método setParseAction:

In [7]:

def very_simple_action():
    print('OK, se ha ejecutado la acción')
    
date.setParseAction(very_simple_action)
print(date.parseString('25/8/2016'))
print(date.parseString('2017-12-08'))

OK, se ha ejecutado la acción
['25', '8', '2016']
OK, se ha ejecutado la acción
['2017', '12', '08']

De la documentación de pyparsing, podemos obtener más información sobre como definir y usar estas acciones:

Podemos definir uno o varias acciones a realizar cuando se produce una coincidencia que activa la regla del parser. Estas acciones pueden ser cualquier objeto de tipo callable de python; es decir, funciones, métodos u objetos instanciados de clases que definan el método mágico __call__.

Las acciones pueden aceptar desde cero hasta tres argumentos, es decir que, dependiendo de como definamos la acción fn, esta será llamada como fn(), fn(toks), fn(loc, toks) o fn(s, loc, toks). El significado de estos parámetros es el siguiente:

s: es la string original que activó el patrón de la regla
loc: es la localización, dentro del texto, de la substring s (Útil para generar mensajes de error)
toks: Una lista de los tokens encontrados, empaquetados en forma de objeto de tipo ParseResults

Si la función quiere modificar los tokens, debe devolver un nuevo valor como resultado de la función, con lo que la lista de tokens devueltos reemplazaría a la original. Si no queremos realizar ningún cambio, la función no debe retornar ningún valor.

Definamos una acción, solo para ver que estos parámetros se pasan efectivamente:

In [8]:

def I_just_wanna_see(s, loc, tokens):
    print('s:', s)
    print('loc:', loc)   
    print('tokens:', tokens)
    print()
    
date.setParseAction(I_just_wanna_see)
print(date.parseString('25/8/2016'))

s: 25/8/2016
loc: 0
tokens: ['25', '8', '2016']

['25', '8', '2016']

Nota: Podemos asignar varias acciones usando el método addParseAction. en ese caso, las acciones se ejecutan de forma anidada, siendo la primera en ejecutarse la primera en añadirse. Cada acción recibe como entrada el resultado de la anterior y pasa su resultado a la siguiente. Veamos un ejemplo:

In [9]:

token = Literal('hola')
token.addParseAction(lambda tokens: 'ei' + tokens[0] + 'ai')
token.addParseAction(lambda tokens: tokens[0].upper())
print(token.parseString('hola'))

['EIHOLAAI']

Si cambiamos el orden en que se añaden las acciones, el resultado puede diferir, lógicamente:

In [10]:

token = Literal('hola')
token.addParseAction(lambda tokens: tokens[0].upper())
token.addParseAction(lambda tokens: 'ei' + tokens[0] + 'ai')
print(token.parseString('hola'))

['eiHOLAai']

Con esto ya podemos definir una acción que nos devuelva un objeto date. Usaremos una acción con un solo parámetro, tokens, la lista de los tokens detectados, ya que no necesitamos los otros parámetros.

Como devolvemos un valor, el parser sustituirá la lista de tokens detectados por ese nuevo valor.

In [11]:

import datetime
​
def get_as_date(tokens):
    first_element = tokens[0]
    if len(first_element) == 4:  # Formato YYYY-MM-DD
        d = datetime.date(
            int(tokens[0]),  # Year
            int(tokens[1]),  # Month
            int(tokens[2]),  # Day
            )
    else:
        d = datetime.date(
            int(tokens[2]),  # Year
            int(tokens[1]),  # Month
            int(tokens[0]),  # Day
            )
    return d
    
date.setParseAction(get_as_date)
print(date.parseString('25/8/2016'))
print(date.parseString('2017-12-08'))

[datetime.date(2016, 8, 25)]
[datetime.date(2017, 12, 8)]

Vamos a parsear valores lógicos

Podemos hacer algo similar con los objetos booleanos. Usaremos una de las funciones auxiliares de pyparsing, oneOf, que nos permite definir de forma rápida un conjunto de literales alternativos. Además se asegura de que siempre intentará capturar el literal más grande, en caso de que haya conflicto entre alguno de ellos; por ejemplo, entre < y <= primero intentará encontrar una correspondencia con el más largo, <=, y si no la encuentra lo intentará con <.

In [12]:

from pyparsing import oneOf
​
boolean = oneOf('1 S Y T True 0 N F False')
print(boolean.parseString('True'))

['True']

Con un poco de mágia en forma de acción asociada a la regla obtendremos valores booleanos de Python. LA API de pyparsing es fluida, por lo que podemos definir la regla y asociar la acción en una sola línea:

In [13]:

def get_as_bool(tokens):
    return tokens[0] in ('1', 'S', 'Y', 'T', 'True')
​
boolean = oneOf('1 S Y T True 0 N F False').setParseAction(get_as_bool)
​
# simple tests
​
assert boolean.parseString('1').pop() is True
assert boolean.parseString('S').pop() is True
assert boolean.parseString('Y').pop() is True
assert boolean.parseString('T').pop() is True
assert boolean.parseString('True').pop() is True
assert boolean.parseString('0').pop() is False
assert boolean.parseString('N').pop() is False
assert boolean.parseString('F').pop() is False
assert boolean.parseString('False').pop() is False
​

Parsear los importes

Nos queda el problema de los importes, que pueden usar como separador decimal la coma, al estilo español, o el punto, al estilo internacional, y las cadenas de textos, que pueden venir limitadas por comillas o no. Los dos casos son fáciles de tratar:

In [14]:

from pyparsing import nums, Word
cost = Word(nums) + oneOf('. ,') + Regex('\d\d')
​
cost.parseString('3819.24')

Out[14]:

(['3819', '.', '24'], {})

La clase Word nos permite definir una palabra, pasandole uno o dos parámetros, que son vocabularios. Los vocabularios se pueden indicar con una string de símbolos, como 'aeiou'. nums es solo una constante definida en pyparsing que vale '0123456789'. Podiamos haber usado una expresión regular, pero Word es bastante interesante.

Si a Word se le pasa un solo vocabulario, define una palabra como una secuencia de n caracteres tomados de los símbolos definidos en el vocabulario.

Si se le pasan dos vocabularios, define una palabra como una secuencia donde el primer caracter debe pertenecer al primer vocabulario y el resto, si los hubiera, al segundo. Por ejemplo, podemos definir un parser para los nombres válidos de Python, que permiten el uso de carateres alfanuméricos y el carácter subrayado, pero no no se permiten que empiece por un dígito:

In [15]:

from pyparsing import alphas, nums, alphanums
​
assert alphas == 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz'
assert alphanums == alphas + nums
​
var_name = Word(alphas + '_', alphanums + '_')
​
var_name.parseString('a')
var_name.parseString('a1')
var_name.parseString('alp_ha')
try:
    var_name.parseString('1uno')
except ParseException:
    # Oops, no se permite el caracter '_'
    pass
​

Definamos otra patrón, incluyendo el símbolo dolar como caracter válido al principio, PERL-style:

In [16]:

var_name_plus = Word(alphas + '$', alphanums + '_')
assert var_name_plus.parseString('a').pop() == 'a'
assert var_name_plus.parseString('$_alpha').pop() == '$_alpha'
assert var_name_plus.parseString('$Alpha_plus').pop() == '$Alpha_plus'

Hecha esta disgresión, volvamos al problema de tratar los importes. Añadamos una acción para obtener un número de tipo Decimal:

In [17]:

from decimal import Decimal
​
def get_as_decimal(tokens):
    int_part, dec_part = tokens
    return Decimal('{}.{}'.format(int_part, dec_part))
​
cost = Word(nums) + Suppress(oneOf('. ,')) + Regex('\d\d')
cost.setParseAction(get_as_decimal)
​
cost.parseString('484432,23')
num_esp = cost.parseString('484432,23').pop()
num_int = cost.parseString('484432.23').pop()
assert num_esp == num_int == Decimal('484432.23')
print(cost.parseString('3.14'))
​

[Decimal('3.14')]

Cadenas de texto con o sin delimitador

Para poder procesar las cadenas de texto, ignorando si procede las comillas delimitadoras opcionales, podemos hacer:

In [18]:

quote = Suppress('"')
content = Regex("[^\";]+") # Cualquier secuencia de caracteres, excepto ; y "
text = quote + content + quote ^ content
​
assert text.parseString('Texto sin comillas').pop() == 'Texto sin comillas'
assert text.parseString('"Texto con comillas"').pop() == 'Texto con comillas'
    

Bueno, ha sido un viaje un poco largo, con paradas en algunos puntos interesantes, pero ya podemos escribir la gramática completa, junto al parser y las acciones aplicadas:

In [19]:

from pyparsing import OneOrMore
# Funciones de conversion
​
def get_as_decimal(s, lok, tokens):
    int_part, _sep, dec_part = tokens
    return Decimal('{}.{}'.format(int_part, dec_part))
​
def get_as_date(s, loc, tokens):
    a, b, c = tokens
    if len(a) == 4:  # Formato YYYY-MM-DD
        return datetime.date(int(a), int(b), int(c))
    else:  # Formato DD/MM/YYYY
        return datetime.date(int(c), int(b), int(a))
​
def get_as_bool(s, loc, tokens):
    return tokens[0] in ('1', 'S', 'Y', 'T', 'True')
​
sep = Suppress(';')
​
quote = Suppress('"') # Texto
content = Regex("[^\";]+") # Cualquier secuencia de caracteres, excepto ; y "
text = quote + content + quote ^ content
text.setParseAction(lambda tokens: tokens[0].strip())
​
boolean = oneOf('1 S Y T True 0 N F False') # Valores lógicos
boolean.setParseAction(get_as_bool)
​
dash = Suppress('-') # Fechas
slash = Suppress('/')
year = Regex('\d{4}')
month = Regex('\d{1,2}')
day = Regex('\d{1,2}')
date = year + dash + month + dash + day ^ day + slash + month + slash + year
date.setParseAction(get_as_date)
​
cost = Word(nums) + oneOf('. ,') + Regex('\d\d')  # Importes
cost.setParseAction(get_as_decimal)
​
line = Group(text + sep + boolean + sep + date + sep + cost)  # One Line
​
lines = OneOrMore(line)  # Lines
lines.setParseAction(lambda tokens: list(tokens))
​
header = Suppress(Regex('.+'))  # Header
​
parser = header + lines + StringEnd() # First rule

La clase OneOrMore nos permite implementar las reglas de una secuencia de uno o más elementos repetidos, como su mismo nombre indica. Pyparsing define muchos más clases de este tipo, como ZeroOrMore, Optional, (Uno o cero), OnlyOne...
La clase Group nos permite agrupar varios tokens en un solo resultado, normalmente porque vamos a tratarlos todos juntos.
La clase StringEnd nos permite indicar que el parser, al consumir este token, debería de haber terminado, es decir, que todo el texto a parserar debe consumirse íntegramente.

Vamos a hacer unas pruebas parseando líneas individuales:

In [20]:

print(line.parseString('Texto sin comillas porque yo lo valgo;Y;2017-08-08;4292.00'))

[['Texto sin comillas porque yo lo valgo', True, datetime.date(2017, 8, 8), Decimal('4292.00')]]

In [21]:

print(line.parseString('"Ahora si que pongo comillas";F;25/8/2014;3200.00'))

[['Ahora si que pongo comillas', False, datetime.date(2014, 8, 25), Decimal('3200.00')]]

In [22]:

print(line.parseString('Ya ves, todo vale;True;1/1/1970;4532,02'))

[['Ya ves, todo vale', True, datetime.date(1970, 1, 1), Decimal('4532.02')]]

print(header.parseString('Comentario;Activo;Fecha;Importe'))  # Ignoramos la cabecera

Y la prueba de fuego, un fichero completo:

In [23]:

source = '''Comentario;Activo;Fecha;Importe
Texto sin comillas porque yo lo valgo;Y;2017-08-08;4292.00
"Ahora si que pongo comillas";F;25/8/2014;3200.00
Ya ves, todo vale;True;1/1/1970;4532,02
'''
g = parser.parseString(source)
for item in g:
    print(item)

['Texto sin comillas porque yo lo valgo', True, datetime.date(2017, 8, 8), Decimal('4292.00')]
['Ahora si que pongo comillas', False, datetime.date(2014, 8, 25), Decimal('3200.00')]
['Ya ves, todo vale', True, datetime.date(1970, 1, 1), Decimal('4532.02')]

Unsado el método parseFile podemos procesar un fichero, si especificamos el nombre, un fichero abierto, o cualquier objeto que implemente una interfaz similar a File:

In [24]:

with open('ejemplo.csv', 'r') as stream:
    g = parser.parseFile(stream)
    for item in g:
        print(item)

['Texto sin comillas porque yo lo valgo', True, datetime.date(2017, 8, 8), Decimal('4292.00')]
['Ahora si que pongo comillas', False, datetime.date(2014, 8, 25), Decimal('3200.00')]
['Ya ves, todo vale', True, datetime.date(1970, 1, 1), Decimal('4532.02')]
['Los espacios no son problema', False, datetime.date(2017, 2, 22), Decimal('1203.23')]

Ventajas de Pyparsing

- **Robusto y sencillo de usar**. Pyparsing lleva más de una década de desarrollo, y se basa en el uso de gramáticas para la definición formal de lenguajes. El paso de la gramática a código Python es casi directo.
​
​
- **Desarrollo incremental, facilmente testeable**. El parser final se puede ir construyendo paso a paso.
​
- No se ve en los ejemplo, pero podemos añadir **validaciones y mensajes de error explicativos** que simplifican la resolución de problemas --incluyendo, por ejemplo, número de línea y posición del error. Podemos asignar nombres a los resultados de los tokens para que seán más sencillos de referencias, y muchas otras funcionalidades que no hemos podido ver aquí.
​
- **Flexible**, comparado con un parser hecho a mano o en base a un montón de espresiones regulares. A modo de ejemplo, véanse los **ejercicios para el lector**.
​

Ejercicios para el lector

Añadir otro formato válido para las fechas, por ejemplo, 10/abr/2017 (10 puntos)
Permitir que la última columna, el importe, acepte también un valor entero, es decir, sin parte decimal (20 puntos)
Permitir que los textos puedan venir sin comillas, con comillas simples o con comillas dobles (20 puntos)
El jefe ha modificado el formato, el fichero tiene ahora una última ĺinea donde va el total acumulado de todos los importes previos, algo así:
```
  Comentario;Activo;Fecha;Importe
  Texto sin comillas porque yo lo valgo;Y;2017-08-08;4292.00
  "Ahora si que pongo comillas";F;25/8/2014;3200.00
  Ya ves, todo vale;True;1/1/1970;4532,02
  12024.02
```
El parser debe adaptarse a este cambio, y comprobar que la suma de los importes coincide con el dato final. Si, ya sé que, técnicamente, esto ha dejado de ser un CSV. Estas cosas pasan. (100 puntos y una gran satisfacción personal)

Mas información

La página web de pyparsing: http://pyparsing.wikispaces.com/

Parsing In Python: Tools And Libraries https://tomassetti.me/parsing-in-python/

PyBirras Edición Pre-veranito (1/jun/2017)

2017-05-22T12:24:00.000+01:00

El próximo 1 de junio, jueves, a partir de las 18:00 tendremos un nuevo encuentro de desarrolladores para hablar de nuestros temas favoritos: desarrollo, unicornios y cervezas. En esta ocasión tendremos tres charlas:

AWS: Desplegando Python en Amazon
PyTesting e integración continua con Travis
Vue.js: El framework javascript para muggles

Tras las cuales tendremos la segunda parte: networking, vida social, risas y ping pong. Todo ello en las instalaciones del Equipo Para (C/La Marina, 4, Santa cruz de Tenerife).
Por favor, confirmad la asistencia en el meetup, para poner las cervezas a enfriar.
https://www.meetup.com/Agile-Canarias/events/235289799/
Esta vez nos hemos venido arriba y tenemos hasta cartel promocional:

El 11 de marzo tendremos el primer PyDay en Canarias

2017-02-16T20:20:00.000+00:00

El 11 de marzo tendremos el primer PyDay en Canarias.Un PyDay es una jornada de un día completo sobre el lenguaje de programación Python, con el formato de unas conferencias pero un poco más dinámico. La cita es en la Sala de Estudio Caja Canarias Campus Anchieta. Como el foro es limitado, debéis inscribiros en esta página, pero, por favor, hacedlo sólo si vais a asistir seguro, si no le estareis quitando la plaza a otros ser humano interesado.

En este caso constará de dos tracks independientes, uno de talleres introductorios y otro de charlas más avanzadas.

Para los alumnos de la Universidad de La Laguna, la asistencia es compatible con un crédito ECTS.

En la web podéis consultar todo el programa del próximo PyDay Tenerife.

Por último, si promocionas el evento por tus redes sociales, te agradeceríamos mucho si incluyeras el Hashtag #PyDayTf.

Mi aportación al #BigCuloDay16

2016-02-15T08:00:00.000+00:00

Un año más llegamos a la IX edición de este -a veces fatalmente incomprendido- llamamiento a la paz, la esperanza y, por que no decirlo, el amor conocido como el Big Culo Day. Esta vez toca un clásico europeo, Natasha, La azafata de maravillosas formas dibujada por François Walthér, y que ahora esta siendo recuperada en una serie de integrales de Dolmen.

Recetas Habituales en Django (Que siempre se me olvidan)

2015-10-16T15:24:00.001+01:00

¿Cómo probar las páginas de errores (404, etc...) en desarrollo?

Para ver esas páginas de error, hay que desactivar la opción DEBUG de la configuración. Pero si lo hacemos, los contenidos estáticos dejan de servirse, así que no podemos estar seguros de como se verán las páginas finales, a no ser que instalemos nuestro propio servidor de contenidos estáticos.
O, por otro lado, podemos usar el flag insecure al llamar a runserver:

manage.py runserver --insecure

Esto obliga al servidor de desarrollo a servir los ficheros a partir de los directorios static de las aplicaciones, aunque la variable settings.DEBUG sea False.

De ninguna manera debemos usar este truco para poner en explotación un servidor de desarrollo de Django. Citando la documentación oficial:

[...] By using this you acknowledge the fact that it’s grossly inefficient and probably insecure. This is only intended for local development, should never be used in production [...]

¿Cómo analizar las consultas SQL que está realizando Django?

Normalmente el primer paso para poder optimizar Django consiste en analizar el número de consultas, así como los tiempos de ejecución de las mismas. Para ello hay una extensión muy recomendable: Django-debug-toolbar.

The Django Debug Toolbar is a configurable set of panels that display various debug information about the current request/response and when clicked, display more details about the panel’s content.

Lo ideal es poner esta app en desarrollo, y no en el despliegue final. Véase la siguiente entrada

¿Cómo tener diferentes entornos de desarrollo/explotación/pruebas?

Mi solución actual, adaptada del muy recomendable libro Two Scoops of Django, consiste en tener un settings.py que será el que se use en despliege y luego un fichero development.py, que simplemente importa todo el contenido del settings.py y realiza las modificaciones que crea oportunas.
Por ejemplo:

from main.settings import *

DEVELOPMENT = True

INSTALLED_APPS += (
    'debug_toolbar',
    )

Para arrancar en desarrollo uso:

manage.py runserver --settings=main.development

¿Cómo hago para que mi método booleano se vea bonito en el admin?

Esta documentado, pero a menudo resulta complicado de encontrar. Si escribimos un método de un modelo que devuelve solo True o False, y lo consultamos en el admin, este nos muestra texto. Sin embargo, para campos definidos como booleanos (BooleanField) nos muestra un icono. Podemos hacer que utilice esos mismos iconos si añadimos un atributo boolean al método.
por ejemplo:

def nacio_en_bisiesto(self):
    year = self.birthday.year
    return year % 4 == 0 and (year % 100 != 0 or year % 400 == 0)

nacio_en_bisiesto.boolean = True

¿Cómo hago para mostrar mi propio contenido html en el admin?

Para que el admin interprete cualquier texto producido por un método como Html, sin escaparlo, debemos asignarle al método en cuestión el atributo allow_tag a True. Es recomendable que nos escudemos de posibles fallos de seguridad usando la función format_html() siempre que incluyamos en la salida texto generado por el usuario final.
Por ejemplo:

def colored_name(self):
    return format_html('<span style="color: #{};">{} {}</span>',
                    self.color_code,
                    self.first_name,
                    self.last_name)

colored_name.allow_tags = True

Taller de Introducción a Django (Casi gratis...)

2015-09-09T17:53:00.000+01:00

Taller Introducción a Django

En las instalaciones de Kreitek / El Andén realizaremos un taller de introducción a Django.

Serán cuatro sesiones, las tardes de los viernes, 25 de septiembre, y 2, 9 y 16 de octubre. las sesiones serán de unas tres horas, incluyendo un descanso para que el personal no desfallezca.
Será necesario llevar un portátil, si puede ser al menos con Python instalado. Versión 2.7 o 3.4, la que se prefiera.
El taller no es gratuito, valdrá 10€ para los no socios del andén y 5€ para los socios. La totalidad del importe irá destinada Al Anden.

Durante el taller realizaremos una aplicación web completa con frontend, backend, modelo de datos y servicios API REST. Se intentará dar una visión extensa de Django, aunque no podremos profundizar mucho en cada tema.

Más información aquí:

http://goo.gl/HI5MhV

Pero... ¿Cómo se llega a El Taller K / El Andén?

Está perfectamente explicado aquí: Taller Kreitek: Donde estamos

Temario

Si se producen cambios en el mismo, los publicaremos en el enlace anterior, pero esto es lo que hay pensado por ahora:

Viernes 25, septiembre

Introducción a Django. Estructura de una aplicación web. Frameworks web. Breve introducción a Python. Instalación de Django. La estructura MVC (Modelo-Vista-Controlador). Nuestro "Hola, mundo" en Django. Qué es una vista. El objeto request. Presentación de la aplicación que vamos a construir en el taller. Risas.

Viernes 2, octubre

Bases de datos. El modelo relacional. Normalización de bases de datos relacionales. Modelos en Django. Campos. El mapeador objeto-relacional en Django. Consultas sencillas a la base de datos. Consultas no tan sencillas. SQL Crudo. Señales y eventos. La aplicación django.contrib.admin. Modelos incluidos: Autentificación y usuarios, grupos, mensajes. Agasajos y loas a los que no han abandonado después del primer día; técnicas de Vudú a lo que si.

Viernes 9, octubre

El sistema de plantillas. Etiquetas (tags) y filtros (filters). Limitaciones --intencionadas-- del sistema de plantillas. Herencia de plantillas. Sistema de carga de plantillas. Creación de nuestras propias etiquetas y filtros. Adaptar un tema de Wordpress a Django. Uso de frameworks como Bootstrap o Purecss. Formularios. Controles y widgets. Formularios desde modelos. Debate: "Cuando usar Django y cuando no".

Viernes 16, octubre

Crear comandos de administración. Ficheros urls.py anidados. Cambios en el sistema de base de datos (migrate). Vistas genéricas. Vistas basadas en clases. Generar contenidos que no son HTML. Crear una API Rest. Despliegue de Django en explotación. Cachés y escalabilidad. Middleware. Internacionalización. Tests con Django. Apps de django recomendables. Té y pastas.

Molón Cartel diseñado por @torehc20

Próxima PyBirras tenerife, el viernes, 4 de junio de 2015

2015-06-04T12:13:00.001+01:00

Este viernes, 5 de junio, a partir de las 19:00, tendremos una nueva reunión de PyBirras Tenerife. Hablaremos, como siempre, de Python, de cervezas, de lo humano y de lo divino (por ese orden). Además, tendremos no una, ni dos, sino tres minicharlas:

NTLK (Natural Language Toolkit), por Hugo Jiménez Hernández
Control de acceso escolar mediante Python, por Sergio Delgado Quintero y David Armas Suárez
Introducción a iPython Notebook, por Juan Ignacio Rodríguez de León

Esta vez nos han invitado a alojar la reunión el equipo de G·koworking, en La Laguna. El lugar es:

Plaza San Honorato, 3, CP 38203
La Laguna / Tenerife
Mapa

Es muy cerca del centro de La Laguna, a menos de 5 minutos de la última parada del tranvía en La Trinidad, en un emblemático local, que durante muchos años fue la "Academia Lázaro".

Como siempre, recordarles que la asistencia es totalmente gratuita, pero se agradecería confirmación de la asistencia, ya sea en el meetup del evento, o vía un twitter a @jileon.

Resumen de política de la semana en curso

2015-05-27T13:55:00.000+01:00

Por fin vemos lo que había detrás de la fachada...

Visto en la lista de correo de Expatriados.

Próxima PyBirras tenerife - Viernes, 13, en el Andén sin Límite

2015-03-10T12:00:00.001+00:00

Este próximo viernes vamos a realizar el tercer encuentro PyBirras. Las PyBirras son reuniones informales en la que hablamos de programación en general y del lenguaje Python en particular. Y beberemos cervezas artesanales canarias (solo si quieres, no es obligatorio [Pero está muy rica]).

En esta reunión hablaremos de las charlas que más nos impactaron en la última PyConEs, y de algunos desarrollos interesantes hechos en El Anden. Y de la vida, el Universo y lo demás.

La asistencia es totalmente gratuita, pero si que te agradecería que confirmaras la asistencia en este meetup:

http://www.meetup.com/Agile-Canarias/events/220564873/

o vía un twitter a @jileon.

PyBirras Tenerife
Viernes 13 de marzo de 2015
18:30 hasta 20:00
Anden Sin límite
Carretera Cuesta Taco, 67, Santa Cruz de Tenerife

Después del evento proyectaremos, para el que quiera quedarse, el documental Indie Game: The Movie. Y pediremos pizza. Y más cervezas.

Si hoy es 16 de febrero, esto es ... Big Culo Day 2015

2015-02-16T22:27:00.000+00:00

La edición anterior no pude participar y me pasé el resto del año arrepentido, esta vez no se repetirá. Con ustedes mi aportación al Big Culo Day 2015: el genial Vittorio Giardino y uno de los culos más redondos de la historia del Comic, Little Ego:

Extra Bonus: Un boceto de Milo Manara de la famosa pose de SpiderWoman, vista desde desde otro ángulo, demostrando una vez más que la lujuria no está solo en el ojo que ve, también está en el punto de mira.

Django Tip: Modify the generated SQL statement of a queryset

2015-02-05T14:15:00.000+00:00

This is my first post in english. I'm doing this as a way to improve my English. If you see something wrong or strange in this article, I'll be pleased if you point it in the comments. Thank you very much in advance.

Nota: Hay una versión en español de este artículo aquí: Django Tip: Modificar la sentencias SQL generada por un queryset.

The extra method of the queryset objects allows us to add some modifications to the SQL statement it will use. Specifically, extra can be used to add new fields to the Select clause, add Tables or Joins to the From clause, and/or add new conditions to the Order By clause.

Suppose we have the usual sock of items for sale, something like that:

class Item(Model):
    id = AutoField(primary_key=True)  # I like to specify the Id.
    description = CharField(max_length=200)
    price = DecimalField(max_digits=12, decimal_places=2)
    created_at = DateTimeField(auto_now_add=True)

We can add a calculated field, just to distinct between items with prices below 5 € of items with a higher price (maybe we want to stamp a low-price icon on the result page, for example). We can use the extra method to add a new calculated field, named "low_price", with the following code:

Item.objects.extra(select={'low_price':'pvp < 5.0'}).all()

Under the hood, what we are doing is transforming the Django generated SQL statement from this:

SELECT app_item.*
  FROM app_item;

to this:

SELECT app_item.*, (pvp <= 5.0) AS low_price
  FROM app_item;

We can add many different calculated fields, either using the dictionary passed as the value of the select parameter, or making several calls to the extra method. For example, if we want to classify the items on three divisions (cheap, under 5€; medium, between 5€ and 100€; and expensive, above 100€), we may do something like this:

Item.objects.extra(select={
    'low_price':'pvp < 5.0',
    'mid_price':'pvp between 5.0 and 100.0',
    'low_price':'pvp > 100.0',
    }).all()

or this other way:

Item.objects  \
    .extra(select={'low_price':'pvp < 5.0'})  \
    .extra(select={'mid_price':'pvp between 5.0 and 100.0'}) \
    .extra(select={'low_price':'pvp > 100.0'})  \
    .all()

Result must be the same in either case.

Reality is that we can get this data with a really simple method on the Item class, but in some cases, it could be very useful to make the Database do the calculations for us.

Clearly, we can add subqueries as new fields in the select clause, which increase the possibilities. As an example, suppose our application have a model to store the ratings our clients give to our products, something like this:

class Score(models.Model):
    id = AutoField(primary_key=True)  # Yes, I know, It's needless...
    item = ForeignKey(Item)
    rate = SmallIntegerField()

We can do a search over our stock, adding the mean rate of every product, calculated by the database itself:

Item.objects.extra(select={
    'mean_rate':'''
        SELECT AVG(app_score.rate)
          FROM app_score
         WHERE app_score.item_id = app_item.id
         '''
    }).all()

We can do the same in our Django Code, writing a simple method in the Item class. But we need a new SQL query to get all the scores of an item, and calculating the average after that.

If we obtain 10 items as a result, for example, we will count up to 11 sql queries to the Database, one for the original search, and one for every item in the result, to get the list of scores. And we have to make the calculation ourself. If we let the Database to make the operation for us, we will count just one SQL query. The difference in performance can be noticeable.

Beware this techniques have a dangerous face: we have linked our code to the Database management system more strongly. That implies more dependencies and more danger. If we use proprietary extensions to the SQL syntax, we got a potential break point. Even a simple call to get the current timestamp -Every Database define his own names: sysdate in Oracle, now() in postgreSQL, current_timestamp in Microsoft SQL Server, to name just a few- will break if we migrate to another database brand.

Nevertheless, it's useful to known that we have this ability. It depends of ourselves to use it or not. Just remember this three little advices:

Explicit is better than implicit. (Tim Peters)

Special cases aren't special enough to break the rules ... Although practicality beats purity. (Tim Peters)

With great power comes great responsibility (Benjamin Parker)

Note: the use of extra to modify the FROM and WHERE clauses is better explained, among other interesting information, in the official docs: Django Query Set API reference - extra.

Django Tip: Modificar la sentencias SQL generada por un queryset

2015-02-05T14:10:00.000+00:00

Note: There is a english version of this post here: Django Tip: Modify the generated SQL statement of a queryset

El método extra de los queryset nos permite realizar algunas modificaciones en las sentencias sql que ejecuta. En concreto nos permite añadir campos a la cláusula SELECT, o tablas y joins a la cláusula FROM, o condiciones a la cláusula ORDER BY.

Supongamos, por ejemplo, que tenemos una tabla de productos a la venta, algo como esto:

class Item(Model):
    id = AutoField(primary_key=True)  # Me gusta especificar la clave
    descripcion = CharField(max_length=200)
    pvp = DecimalField(max_digits=12, decimal_places=2)
    alta = DateTimeField(auto_now_add=True)

Podemos añadir un campo calculado que nos indique si los precios son inferiores a 5.0 (quizá queremos marcar estos productos en la página con un icono de "low-price", por ejemplo). Para ello, podemos añadir un campo calculado al select de la query usando extra, como en el siguiente ejemplo:

Item.objects.extra(select={'low_price':'pvp < 5.0'}).all()

Lo que estamos haciendo es que la sentencia SQL generada por Django pase de esto:

SELECT app_item.*
  FROM app_item;

a esto:

SELECT app_item.*, (pvp < 5.0) AS low_price
  FROM app_item;

Podemos pasar varios campos calculados en el diccionario especificado por el parámetro select, o hacer varias llamadas a extra. Por ejemplo, si queremos clasificar los precios en tres bandas, (baratos, por debajo de 5 euros; medios, entre 5 y 100 euros y caros, por encima de 100 euros), podemos hacerlos así:

Item.objects.extra(select={
    'low_price':'pvp < 5.0',
    'mid_price':'pvp between 5.0 and 100.0',
    'low_price':'pvp > 100.0',
    }).all()

O así:

Item.objects  \
    .extra(select={'low_price':'pvp < 5.0'})  \
    .extra(select={'mid_price':'pvp between 5.0 and 100.0'}) \
    .extra(select={'low_price':'pvp > 100.0'})  \
    .all()

El resultado debería ser el mismo en los dos casos.

Es verdad que podemos realizar este calculo de bandas de precios en un simple método de la clase Item, pero en ocasiones puede sernos útil o necesario que determinadas operaciones las haga la base de datos por nosotros.

Obviamente también podemos pasar subconsultas como campo añadido al select, que nos da aun más posibilidades. Por ejemplo, supongamos que en nuestra aplicación tiene otro modelo con las puntuaciones que nuestros clientes asignan a nuestros artículos, algo como esto:

class Score(models.Model):
    id = AutoField(primary_key=True)  # Si, ya lo sé, no hace falta...
    item = ForeignKey(Item)
    rate = SmallIntegerField()

Podemos realizar una consulta sobre artículos e incorporar la puntuación media de cada uno, calculada directamente por el gestor de la base de datos:

Item.objects.extra(select={
    'mean_rate':'''
        SELECT AVG(app_score.rate)
          FROM app_score
         WHERE app_score.item_id = app_item.id
         '''
    }).all()

Si quisiéramos hacerlo desde Django, con un método de la clase Item, por ejemplo, tendríamos que realizar primero una consulta para obtener todas las puntuaciones de un artículo, y luego calcular la media.

Si lo hacemos para una consulta cuyo resultado final fueran 10 artículos, por ejemplo, tendríamos que hemos realizado 11 consultas SQL a la base de datos, haciendo además el cálculo nosotros, por una sola consulta, si los cálculos los realiza el SGBD. La diferencia en rendimiento puede ser considerable.

Estás prácticas también tienen su lado peligroso: hemos vinculado más nuestro código al gestor de base de datos que estamos usando, con las dependencias y peligro que eso conlleva. Si usamos extensiones propietarias de la base de datos para realizar la consulta, aunque sea algo tan simple como utilizar la marca de tiempo de la base de datos (Que cada gestor se empeña en definir de forma diferente, sysdate en Oracle, now() en postgreSQL, current_timestamp en Microsoft SQL Server, por citar solo unos pocos ejemplos), ya tenemos un punto de ruptura si pretendemos migrar de gestor.

En cualquier caso, es útil saber que tenemos esta capacidad, ya depende de nosotros si queremos emplearla o no. Recuerda solo estos tres consejos:

Explícito mejor que implícito (Tim Peters)

Los casos especiales no son tan especiales como para romper las reglas ... pero lo práctico vence a lo ideal (Tim Peters)

Todo gran poder conlleva una gran responsabilidad (Benjamin Parker)

Nota: El uso de extra para modificar las cláusulas FROM y WHERE está explicado, junto con muchas otras cosas interesantes, en la documentación oficial: Django Query Set API reference - extra.

A quien critica a Siriza por no poner mujeres en su gobierno.

2015-01-29T11:11:00.002+00:00

Reconozco que tengo un problema con la prensa de este país: No me creo su independencia.

La última patochada son las airadas protestas porque el nuevo gobierno de Grecia no cuenta con mujeres entre sus miembros. Que haya subido el salario mínimo o haya garantizado la electricidad a los más pobres no importa. Peor aun, es populista. Permitidme que os lo diga: ¡Qué falso os queda!

¿Sabes cuántas mujeres había en el gobierno anterior de Grecia? ¿Y en el anterior a este? ¿Y en el anterior al anterior a este? (Spoiler alert: Más bien tirando a pocas tirando a ninguna).

¿Por qué no os preocupó ENTONCES? ¿Dónde estaba vuestra justa ira? ¿Cómo se os pudo pasar tan por alto como para no denunciarlo NI UNA SOLA VEZ?

¿Cuantas mujeres hay ahora mismo en el Gobierno de EEUU? (Spoiler alert: Una. En un ministerio de chichinabo, por cierto)

¿Por qué no os preocupa AHORA? ¿Por qué no os rasgáis las vestiduras por el machismo patriarcalista de Obama?

Son preguntas sencillas pero no os preocupéis, ya contesto yo por vosotros: La república Griega y su gobierno os chupa un pie. La igualdad de la mujer os importa tres cominos. La Equidad os la refinfanfinfla pero bien. No sois más hipócritas porque no entrenáis.

En resumen: No cuela.

PD: De propina, un pequeño cuento (after Augusto Monterroso):

Cuando el dinosaurio despertó, Podemos seguía allí.

PD2: Cuando hablo de prensa, no incluyo a artefactos bélicos como La Razón, Libertad Digital y similares, manojos de papeles/bits juntados al tuntún para hacer bulto y mantener la ilusión entre los más adoctrinados, medios comprados (y vendidos) desde su mismo nacimiento. Hablo de cabeceras con bagaje histórico, como El País, ABC o El Mundo (No enlazo porque ahora es delito, se siente). Los que ahora agachan la cabeza y obedecen prestos la voz de su amo, mientras se quejan de que las ventas en papel bajan. Y se pregunta el porqué.

La auténtica #MarcaEspaña de Rajoy: Spain WTF

2015-01-29T09:15:00.001+00:00

No creo que la foto sea real...^*

... pero quizá sea el origen de un nuevo y exitoso Hashtag: #SpainWTF

^*No voy ni a molestarme en comprobarlo.

Segunda reunión PyBirras/Tenerife

2014-06-04T10:31:00.002+01:00

Mañana (5/junio/2014) tendremos la segunda reunión de PyBirras Tenerife. Será a partir de las 7 de la tarde en el Café Teatro 7. Si te animas a ir, apúntate en esta página de Meetup que el equipo de Agile Canarias nos ha prestado:

http://www.meetup.com/Agile-Canarias/events/184537892/

En principio la idea es tomarnos unas cervezas y hacer tres breves presentaciones (aproximadamente de 10 minutos) sobre los siguientes temas:

Guía de supervivencia para Python3.4 (por Juan Ignacio)
SublimeText3; IDE Python (por Héctor)
Testing de aplicaciones en Django (por Esaú)

Lipdub del Colegio Nuryana 2014

2014-05-29T14:34:00.000+01:00

Cuando veo que hacen estas cosas en el colegio donde tengo a mis retoños se me pone un nudo en la garganta...

En fin, ¡Absolutamente Awesomico! Se me han rallado los ojos, pero debe ser por la cebolla que estoy picando, ojo.

¡A todo Kanban! Una introducción a Kanban

2014-05-09T10:42:00.002+01:00

El otro día di una pequeña introducción a la herramienta Kanban, gracias al grupo de Agile Canarias. Esta es la presentación que utilicé, con un par de correcciones y añadiendo dos páginas nuevas con referencias a algunas herramientas software y add-ons para implementar Kanban de forma digital (Aunque sigo recomendado empezar con la combinación baja tecnología/bajo coste: un tablero o pizarra de ikea, cinta adhesiva y notas Post-it)

¡A todo Kanban! ~ Introducción a kanban from Juan Rodríguez

Gracias a los asistentes, espero que les haya gustado la presentación y la pequeña actividad ludico-educativa del final :-)

Fui a la Tenerife Startup Weekend (Y gané un montón de amigos)

2014-03-28T12:47:00.000+00:00

El pasado fin de semana participé en la StartUp Weekend Tenerife, segunda edición. Había quedado desconsolado por no participar en la primera, así que, a pesar de tener muchísimo trabajo, a última hora me lié la manta a la cabeza y me inscribí. La suerte me sonrió y al final pude pasar todo el fin de semana asombrado de la cantidad de talento, las ganas de trabajar, la abundancia de ideas y el volumen de trabajo que se puede hacer en un fin de semana.

Los ganadores de la presente edición son el equipo Dtapapp (Ya los puedes seguir en twitter: @dtapapp), cuyo atractivo concepto es La ruta de la tapa todo el año. Desde aquí felicito al equipo por la cantidad de cosas que pudieron realizar, desde pivotar de la idea original, que ciertamente no me parecía tan interesante, a validar la propuesta, conseguir un ratio de conversiones altísimo, aun siendo sábado, hacer una beta de la aplicación e incluso ejecutar una prueba real ¡Con cartel y todo! Para quitarse el sombrero. Sobra decir que desde aquí me apunto como usuario en pruebas, creo que doy el perfil.

El segundo premio fue para Gifteapp (@gitfapp en twitter), una aplicación pensada para ayudarte a hacer el regalo perfecto, que me pareció muy interesante por la parte de IA y aprendizaje automático (Machine Learning) que creí entender que se construiría por detrás.

El tercer premio fue para Gamehab, (@gamehab en twitter), una aplicación que consiste en una serie de ejercicios para la rehabilitación de afectados por el síndrome de túnel carpiano, aunque extensible a otras dolencias. Me gustó mucho la forma en que enfocaron el retorno de beneficios, habrá que ver si es o no factible. En cualquier caso, muy interesante y personalmente creo que bastante viable.

Otro proyecto muy interesante, que arrasó con el resto de premios, fue Seiku (@SeikuTales en Twitter), una plataforma para crear historias interactivas, del estilo de los libros de Elige tu propia aventura, que se hicieron populares en la década de los 80, pero actualizados a los tiempos modernos y con múltiples detalles que potencian la idea. Además, tenían el logo más súper molón de todos, felicidades a la diseñadora.

Mi equipo era 3DAlize (@3DAlize en twitter). Presentamos una idea cuyo eslogan es materializa tu experiencia cultural. No ganamos ni para pipas [Yes, pun intended]. La competencia de verdad que era algo serio. Además, me despisté con el tiempo de la presentación y no pudimos ni enseñar el prototipo. Mea culpa. Aun sin ese fallo, no creo que hubiéramos ganado, porque nos alejamos bastante de los parámetros fijados para el concurso. Pero como dicen en mi pueblo, de todo se aprende. En cualquier caso, no cambiaría nada de lo hecho en el fin de semana, tanto el brusco pivotaje como la cantidad de ideas y conceptos con los que trabajamos. Además, el equipo que me tocó era de auténtico lujo. Me lo pasé increíble todo el fin de semana, aprendí un montón y conocí a muchísima gente nueva e interesante. No se puede pedir más.

Por supuesto, felicitar muy mucho al equipo que ha organizado la StartUp Weekend Tenerife: La organización ha sido espléndida, el catering me sorprendió muy positivamente, algo que no me extraña teniendo a un sibarita como Jacob Rodríguez en el equipo, los coachers ayudaron y se comprometieron hasta el tuétano, Luis Paris Carmona, por ejemplo, que nos dio una charla durante la cena del primer día que nos dejó asombrados, patidifusos y con ganas de más. Fue un descubrimiento el ver la seriedad, empeño e interés que le puso a su trabajo el fotógrafo y realizador Iombi García (Gracias por la foto del equipo), un auténtico puntal cuyo trabajo habrá que seguir muy de cerca. Lo mejor de todo, pude reencontrarme con gente muy apreciada y físicamente dispersa, como Rafa Torres y David Macias, lo que fue la guinda del pastel.

No sé si podré apuntarme el año que viene, pero seguro que lo intentaré. Y animo a todo el mundo a probar la experiencia; es un evento interesante para cualquiera y seguro que lo vas a pasar mejor que viendo Sálvame de Luxe en la tele.

La Gran Estafa Española (Spanish Bisne)

2014-02-10T21:09:00.001+00:00

Cada vez que veo el cartel de la película La Gran Estafa Americana, mi cerebro la reinterpreta así:

(Si pinchas en la imagen podrás verla más grande en flickr)

PD: Creo que la postura de chuloplaya de Wert le queda que ni pintada.

El FAQ definitivo sobre la Homeopatía

2013-12-05T13:07:00.000+00:00

Todo lo que siempre quisiste saber sobre la homeopatía

pero nunca llegaste a preguntar porque, siendo sinceros

te importaba una mierda.

¡En rigurosa exclusiva!

Pregunta: ¿Funciona la homeopatía?

Respuesta: No

Pregunta: ¿Pero y si ...?

Respuesta: Que no. Pesao.

El Ornitorrinco Enmascarado

Django: Actualizar un contador en un modelo

Actualizar un contador en un modelo en Django

The return of the Masked Platyplus

Cristina Cifuentes roba en un supermercado, ahora con banda sonora

Cómo determinar si un archivo es una imagen PNG

Buscar archivos PNG con otra extensión

Uso del decorador functools.wraps en Python

Ejemplo de uso de pyparsing

Nota: La versión más actualizada de este documento está siempre en

https://github.com/euribates/Charla-DSL/blob/master/Ejemplo-uso-pyparsing.ipynb

Ejemplo de uso de pyparsing

Ejemplo de datos a procesar

Algo como esto: Comentario;Activo;Fecha;Importe Texto sin comillas porque yo lo valgo;Y;2017-08-08;4292.00 "Ahora si que pongo comillas";F;25/8/2014;3200.00 Ya ves, todo vale;True;1/1/1970;4532,02

Una gramatica para estos ficheros

Implementación con pyparsing

Parseando fechas

Reglas de parseo

Vamos a parsear valores lógicos

Parsear los importes

Cadenas de texto con o sin delimitador

Ventajas de Pyparsing

Ejercicios para el lector

Mas información

La página web de pyparsing: http://pyparsing.wikispaces.com/ Parsing In Python: Tools And Libraries https://tomassetti.me/parsing-in-python/

PyBirras Edición Pre-veranito (1/jun/2017)

El 11 de marzo tendremos el primer PyDay en Canarias

Mi aportación al #BigCuloDay16

Recetas Habituales en Django (Que siempre se me olvidan)

¿Cómo probar las páginas de errores (404, etc...) en desarrollo?

¿Cómo analizar las consultas SQL que está realizando Django?

¿Cómo tener diferentes entornos de desarrollo/explotación/pruebas?

¿Cómo hago para que mi método booleano se vea bonito en el admin?

¿Cómo hago para mostrar mi propio contenido html en el admin?

Taller de Introducción a Django (Casi gratis...)

Taller Introducción a Django

Más información aquí:

Pero... ¿Cómo se llega a El Taller K / El Andén?

Temario

Viernes 25, septiembre

Viernes 2, octubre

Viernes 9, octubre

Viernes 16, octubre

Molón Cartel diseñado por @torehc20

Próxima PyBirras tenerife, el viernes, 4 de junio de 2015

Resumen de política de la semana en curso

Próxima PyBirras tenerife - Viernes, 13, en el Andén sin Límite

Si hoy es 16 de febrero, esto es ... Big Culo Day 2015

Django Tip: Modify the generated SQL statement of a queryset

Django Tip: Modificar la sentencias SQL generada por un queryset

A quien critica a Siriza por no poner mujeres en su gobierno.

La auténtica #MarcaEspaña de Rajoy: Spain WTF

Segunda reunión PyBirras/Tenerife

Lipdub del Colegio Nuryana 2014

¡A todo Kanban! Una introducción a Kanban

Fui a la Tenerife Startup Weekend (Y gané un montón de amigos)

La Gran Estafa Española (Spanish Bisne)

El FAQ definitivo sobre la Homeopatía

Todo lo que siempre quisiste saber sobre la homeopatía

pero nunca llegaste a preguntar porque, siendo sinceros

te importaba una mierda.

¡En rigurosa exclusiva!

Algo como esto:

`Comentario;Activo;Fecha;Importe Texto sin comillas porque yo lo valgo;Y;2017-08-08;4292.00 "Ahora si que pongo comillas";F;25/8/2014;3200.00 Ya ves, todo vale;True;1/1/1970;4532,02`

La página web de pyparsing: http://pyparsing.wikispaces.com/

Parsing In Python: Tools And Libraries https://tomassetti.me/parsing-in-python/