DEV Community: ninja-ia

¿Cuánto tarda un borracho en ganar al Pacman?

ninja-ia — Fri, 14 Aug 2020 17:30:02 +0000

En esta serie de artículos vamos a estudiar un aspecto de los más dinámicos de la inteligencia artificial: el desarrollo de robots.
No tanto como Skynet (todavía), pero sí que pueda realizar alguna tarea como un humano: jugar al Pacman.
Para eso necesitamos armar un Pacman; vamos a hacer un Pacman más sencillo, en el que no hay fantasmas.

Aprovechemos que no hay fantasmas para hacer jugar a un tipo de jugador que probablemente sobreviviría poco: un borracho jugando al Pacman.
El borracho jugando al pacman juega completamente al azar.
En cada momento elige de forma aleatoria para dónde va en el siguiente paso: para arriba, para abajo, para la izquierda o para la derecha.

Les pregunto entonces: en el nivel inicial (que es este que copiamos aquí) y sabiendo que el pacman se desplaza a una velocidad aproximada de 10 casilleros por segundo, ¿cuánto tiempo dicen que tardaría un borracho en comerse todas las bolitas?

En la sección que sigue vamos a describir un poco cómo fue el diseño y la implementación del Pacman en Python.
Si no les interesa tanto esto, pueden saltearla e ir directamente a la sección resultados.

El Pacman

Vamos a describir el estado del juego Pacman en la clase Estado.
Esta clase va a tener (por ahora) los siguientes atributos:

mapa: un array bidimensional que tiene 1 cuando hay una bolita, 0 cuando está vacío y -1 cuando el lugar está prohibido
posicion: la posición en la que se encuentra el Pacman
puntaje: cuántas bolitas comió
cantidad_pasos: cuántos pasos hizo

Quiero aclarar aquí que hay una decisión bastante discutible en cuanto a diseño: que la posición del Pacman forme parte del Estado.
Quizás (seguramente, incluso) sea mejor pensar tres clases: Pacman, Mapa, Fantasma y que el estado del juego sea una composición de las tres (ya sea en una clase o no).
Esta estrategia de diseño la vamos a usar más adelante, pero por ahora (para nuestro objetivo), con esto es suficiente.
Cuando queramos seguir (no voy a poner más spoilers) vamos a ver cómo adaptamos esta funcionalidad a un diseño un poco más sofisticado.

Por ahora, este Estado se encarga de todo.
Afortunadamente, igual, todo es bastante poco en este caso: sería avanzar una posición y saber si se terminó el mapa:

Avanzar una posición

def avanzar_posicion(self, accion: np.ndarray):
    nueva_posicion = self.posicion + accion
    if nueva_posicion[0] == np.shape(self.mapa)[0]:
        nueva_posicion[0] = 0
    elif nueva_posicion[0] == -1:
       nueva_posicion[0] = np.shape(self.mapa)[0] - 1
    if nueva_posicion[1] == np.shape(self.mapa)[1]:
        nueva_posicion[1] = 0
    elif nueva_posicion[1] == -1:
        nueva_posicion[1] = np.shape(self.mapa)[1] - 1
    self.cantidad_pasos += 1
    if self.mapa[tuple(nueva_posicion)] != -1:
        self.puntaje += self.mapa[tuple(nueva_posicion)]
        self.posicion = nueva_posicion
        self.mapa[tuple(nueva_posicion)] = 0

avanzar_posicion toma accion, un array de dos posiciones: cuánto se mueve en las filas y en las columnas (+1, 0, -1), de modo que quedan codificados los movimientos:

[1, 0] = ↓: sumar una fila es análogo a ir para abajo
[-1, 0] = ↑: restar una fila es análogo a ir para arriba
[0, 1] = →: sumar una columna es análogo a ir para la derecha
[0, -1] = ←: restar una columna es análogo a ir para la izquierda

Avanzar posición es bastante fácil, es cuestión de posicion_nueva = posicion_actual + accion.
Luego de eso hay un par de cosas extra:

Si el Pacman "se cae del mapa", aparece del otro lado: eso son las siguientes 8 líneas.
El mapa se actualiza sólo si la nueva posición no está prohibida.
Cuando se mueve, al puntaje le sumamos lo que estaba en esa posición (1 si había una bolita, que se comió), y pasamos esa posición a 0.

Terminó el mapa

@property
def completo(self):
    return not (self.mapa == 1).any()

Éste lo agregamos únicamente porque tiene el decorador property, que quizás no lo conozcan todos.
Podríamos tener pronto un lindo artículo sobre decoradores en Python, pero brevemente: @property permite que el método sea llamado como un atributo.
Es decir, que el mapa esté completo o no lo sabemos sólo haciendo una cuenta, no podemos configurarlo fácilmente como un atributo sin más.
Más aún, uno no debería poder modificar el completo desde afuera de la clase Estado.
En muchos lenguajes esto se resuelve con lo que se llaman getter/setter: en vez de que exista el atributo completo existe el método get_completo(), que hace la cuenta necesaria.
En Python, eso se resuelve de una forma súper limpia con los @property.

Bonus: `str`

Tenemos que imprimir el estado del juego de alguna manera.
Una posibilidad es hacer una función que toma el estado y genera un string, pero Python viene preparado para eso.
Cuando escribimos print, llamamos (básicamente) al método __str__ de la clase.
Es decir, si modificamos __str__, podemos hacer que print(estado) imprima en pantalla directamente el mapa como queremos.
Quizás podemos hacer más adelante una nota de __str__, __repr__ y similares, pero por ahora vamos a centrarnos en esta implementación.
Queremos que el dibujo primero diga cómo va el juego (puntaje y cantidad de pasos) y luego dibuje un cuadrado lleno cuando hay una pared (o sea, está prohibido), un espacio vacío cuando no hay nada y un puntito cuando hay una bolita.
Además, al pacman lo vamos a simbolizar con una O.
Así, queda

def __str__(self):
    dibujo = f'puntos: {self.puntaje}, pasos: {self.cantidad_pasos}\n'
    for i, row in enumerate(self.mapa):
        for j, val in enumerate(row):
            if (np.array([i, j]) != self.posicion).any():
                if val == 1:
                    dibujo = dibujo + '·'
                elif val == 0:
                    dibujo = dibujo + ' '
                else:
                    dibujo = dibujo + '█'
            else:
                dibujo = dibujo + 'O'
        dibujo = dibujo + '\n'
    return dibujo

y esto va a salir cada vez que hagamos print(estado).

Resultados

¿Cómo se "juega" a este pacman entonces?
Creamos un estado a partir de un mapa y, mientras no esté completo, elegimos una acción al azar y avanzamos el estado:

estado = Estado(mapa)
while not estado.completo:
    accion = random.choice(acciones)
    estado.avanzar_posicion(accion)
print(f"Terminé en {estado.cantidad_pasos} pasos")

Este código lo ejecutamos (agregándole algún que otro print y sleep para que se pueda ver) y tenemos un Pacman que se mueve al azar en un mapa.
Como ejemplo, aquí va el resultado cuando el mapa es un mapa de 5x5 sin paredes:

En este ejemplo el borracho tardó <> pasos en completar el juego, que a 10 bolitas por segundo es lo mismo que tardar <> segundos.
Obvio que éste fue un caso en particular, y tiene ese random por ahí.
¿Qué pasa si lo ejecutamos muchas veces?
¿Cuánto da en promedio la cantidad de pasos?
A continuación va el histograma con 10 mil iteraciones.

En este histograma el promedio es 117.28 pasos (y la desviación estándar 41.67): aproximadamente 12s en resolver el mapa por completo.

Antes de responder la pregunta del borracho jugando al Pacman, perdón si me voy un poco por las ramas, pero me surgió la pregunta: ¿cómo depende la cantidad de pasos del tamaño del mapa?

Dependencia con el tamaño

Estaba relativamente fácil: poner el código anterior en un loop que vaya haciendo el barrido para los distintos lados y guardar pasos promedio y desviación estándar.
Resulta (de esto me enteré gracias a Patu Groisman, síganlo en twitter que es un capo) que este resultado fue encontrado teóricamente hace muuuy poco, y para tamaños muy grandes de mapa tiende a la forma 4 * (n log n)^2/pi.

Así sale este gráfico:

Fíjense que hay una diferencia considerable, pero se va a ir achicando a medida que agrandemos n.[^1]

Ahora sí, ¿cuánto tarda el borracho?

Con todo lo que hicimos, lo que queda es armar el mapa, que se ve así (un poquito más feo que el original, no?):

Y el histograma de pasos queda:

En promedio son 6999.2 pasos, con desviación estándar 2657.
Con los tiempos que dijimos, de 10 pasos por segundo, a un borracho le llevaría ¡11 minutos! ganar al Pacman si no hubiera fantasmas.

Todo este código está subido en un repo particular, que pueden chusmear, clonar, forkear y otros neologismos: https://www.github.com/ninja-ia/pacman

Y ahora, ¿qué?

Podríamos quedarnos aquí, sí... pero nos gusta el Pacman y esto es un blog de Inteligencia Artificial.
Dejamos para la próxima edición la pregunta: ¿cómo le enseñamos al borracho a jugar al Pacman? ¿Y a los fantasmitas?
Nos vemos la próxima!

[1]: Con este modelo, es demasiado costoso hacer las cuentas para n grandes, pero quizás luego completaremos este resultado con tamaños más grandes

Detección en YOLO, frame por frame

ninja-ia — Mon, 20 Jul 2020 12:38:39 +0000

La visión por computadora es una de las áreas del aprendizaje automático con mayor cantidad de avances en los últimos tiempos y, sin embargo, donde también quedan aún muchos problemas por resolver. Dentro de este campo podemos pensar en varias subdivisiones según la tarea realizar, por ejemplo, clasificación de imágenes, detección de objetos, procesamiento de imágenes y un largo etcétera. En este artículo vamos a trabajar en el problema de la detección de múltiples objetos en imágenes utilizando YOLO+Darknet, una de las combinaciones más potentes para tal tarea.

YOLO (You Only Look Once) es una arquitectura de red convolucional propuesta originalmente por Joseph Redmon, Santosh Divvala, Ross Girshick y Ali Farhadi [https://arxiv.org/abs/1506.02640]. Con el paso del tiempo se han realizado diversas mejoras a la arquitectura original y al día de hoy se encuentra disponible YOLOv4, su última versión. Aunque es posible implementar la arquitectura de YOLO en diversas plataformas, quizás la más conveniente para tal fin es la que brinda Darknet.
Darknet es un framework pensado para implementar distintas arquitecturas de redes buscando la mayor eficiencia de cómputo. La contrapartida que tiene es una mayor dificultad de implementación comparado con otros frameworks más conocidos como TensorFlow o Pytorch.

En este artículo no pretendemos explicar la arquitectura ni el funcionamiento de YOLO. Lo que haremos, en cambio, es mostrar cómo utilizar la implentación de Darknet y cuáles son las primeras dificultades que pueden aparecer cuando intentamos hacer esto utilizando Python. Primero, sin embargo, vamos a mencionar muy brevemente el principio de funcionamiento de una red convolucional para ubicar en contexto el problema que estamos intentando resolver.

Si pensamos en una imagen representada por una matriz, donde cada píxel es un valor numérico, podemos pensar también en que alguna transformación sobre esta imagen no es otra cosa que una transformación sobre la matriz original. En particular se suele pensar en las imágenes como la composición de 3 matrices, una por cada color RGB. Dentro del campo del procesado de imágenes una transformación comúnmente utilizada es la convolución. Convolucionar una imagen (matriz) con un filtro (matriz) da como resultado una nueva imagen más pequeña que la original. Esta imagen tendrá una u otra característica según el filtro que se haya utilizado a la hora de convolucionar. Algunos filtros muy comunes son aquellos que buscan bordes en la imagen (edge), aquellos que la difuminan (blur), etcétera. Estos filtros sirven para, en definitva, extraer o resaltar alguna propiedad (feature) de la imagen original. Estas propiedades filtradas pueden aportar información relevante sobre la imagen original y esta puede ayudar en un proceso de clasificación, de identificación de objetos o de cualquier otra tarea que uno pueda pedirle a una red neuronal.

La pregunta entonces es cómo pasarle esta información adicional (filtrada de la imagen original) a una red neuronal. La respuesta a este problema viene dado por las redes convolucionales. En ellas uno pasa sólo la imagen original como input. Luego, en las capas convolucionales, cada neurona (convolucional) aplica un filtro a la imagen que llega de la capa anterior y entrega como resultado una nueva imagen filtrada. Y entonces, ¿qué filtro aplican estas capas convolucionales?. La respuesta es ninguno en especial. Las redes convolucionales heredan la filosofía de las redes multiperceptrón donde cada neurona entrena sus pesos y por lo tanto la operación que esta realiza sobre la entrada. En las neuronas convolucionales lo que se entrena es el filtro aplicado a la entrada. Es más: podemos aplicar muchas capas convolucionales, de modo que cada capa aplica una serie de filtros sobre las imágenes provenientes de las capas anteriores. Esto permite "apilar" una sucesión de filtros donde cada uno recoge alguna característica distinta de la imagen. Esta lógica permite una inmensa flexibilidad y un potencial enorme a la hora de extraer información sobre una imagen original. Finalmente, al final de las capas convolucionales se suele agregar alguna capa multiperceptrón para que esta actúe como clasificador, regresor, etcétera.

Bajo esta lógica es que funcionan las redes convolucionales y en particular la arquitectura de YOLO. Teniendo esto presente es que vamos a utilizar el framework de Darknet [https://pjreddie.com/darknet/] para implementar YOLO y mostraremos los primeros problemas a los que uno se enfrenta cuando decide utilzar Python para tal fin. Utilizaremos para la tarea YOLOv3.

Veamos...

Siguiendo la guía de instalación de Darknet de su página oficial, encontramos una explicación de cómo realizar una detección usando el ejecutable generado después de compilar. Sin embargo, es también posible hacer lo mismo utilizando el archivo darknet.py que ya viene en el paquete. Este código de Python tiene un conjunto de funciones que nos permiten realizar una detección sobre la imagen seleccionada, con el simple requerimiento de que especifiquemos la dirección de la carpeta contenedora de la imagen. Esto se consigue en la línea

  r = detect(net, meta, b"/direction/image.jpg")

que está dentro de la función main al final del archivo. El resultado de la detección se entrega cuando corremos el archivo darknet.py en la consola.

Tengan en mente que este archivo está escrito para Python 2, que ya está deprecado dado que ahora existe Python 3, el cual recomendamos usar. Es necesario entonces implementar unos cambios en el archivo antes que nada:

Todas las direcciones de los archivos deben llevar una b delante de las comillas de la dirección. Esto se debe a un cambio de formato en los archivos. El formato no es un string, sino del tipo bytes, y en Python 3 esto debe ser especificado.
Las direcciones en net y meta (la red, los pesos y los nombres) deben ser cambiados, y también la dirección del archivo libdarknet.so en la línea lib.
Además, existe ahora yolov3 así que es posible descargarlo y usar los nuevos pesos y la red.
Cuidado con la dirección del archivo coco.names que se especifica dentro de coco.data en la carpeta cfg/, es necesario añadirle la dirección completa.
No se olviden de añadir los paréntesis correspondientes en las líneas de print (esto es necesario en Python 3).

Ahora vamos al grano, el interés de esta publicación es realizar la detección de un video frame por frame. La función VideoCapture del paquete cv2 procesa el video y es posible leer y guardar cada frame usando read(). Pero el archivo darknet.py no entiende el formato de frame; necesita una imagen. Para poder correr la red en un video es necesario convertir los frames a formato imagen, y para lograrlo escribimos una función que explicamos más abajo.

Nuestra función

Utilizaremos la función de detección en darknet.py, así que es menester alimentarla con algo que pueda digerir. Así es que necesitamos saber qué es. Notamos que detect carga la imagen utilizando la función load_image, una función de C que darknet.py traduce a Python. Buscándola, descubrimos que está escrita en el archivo image.c dentro del directorio src/, y que llama a la función load_image_stb escrita algunas líneas arriba en el mismo archivo. La salida de esta función es la entrada de detect con lo cual nos dice cuál es el formato deseado para el frame. En este caso es la clase darknet.IMAGE, definida por

class IMAGE(Structure):
    _fields_ = [("w", c_int),
                ("h", c_int),
                ("c", c_int),
                ("data", POINTER(c_float))]

Recuerden que una imagen tiene una altura h, un ancho w, h*w píxeles y tres colores por cada píxel: un triplete [x,y,z], donde cada uno va desde cero a uno. Entonces tenemos h*w*3 números para definirla. Un frame es un de la clase numpy.ndarray. Necesitamos tener una clase darknet.IMAGE para que la función detect pueda leerla.

Pero lo que tenemos a partir de la lectura de cv2 son frames. Un frame es un array con tres coordenadas donde las dos primeras refieren a la posición, con coordenadas h y w y la tercera al vector de colores. Podemos pictorizarlo como

   [ [[x1 y1 z1], [x2 y2 z2],... [xn yn zn]], [[xn+1 yn+1 zn+1],... ], ... ]

y estos números corren de cero a 255: son coordenadas RGB.

En principio, podemos usar este array como la cuarta entrada de la función IMAGE, pero esto no funcionará. Por qué y cómo resolverlo puede ser encontrado en la función load_image_stb, previamente mencionada,

image load_image_stb(char *filename, int channels)

En particular, hay una parte del código donde podemos ver cómo es el formato de salida,

for(k = 0; k < c; ++k){
        for(j = 0; j < h; ++j){
            for(i = 0; i < w; ++i){
                int dst_index = i + w*j + w*h*k;
                int src_index = k + c*i + c*w*j;
                im.data[dst_index] = (float)data[src_index]/255.;
            }
        }
    }

Esto define el correcto ordenamiento del vector. Siguiendo la notación de arriba, donde (xi, yi, zi) es el triplete de la coordenada i, el vector de entrada de IMAGE debe tener la pinta

[z1, z2, z3, ..., y1, y2, y3, ..., x1, x2, x3, ...]

Ahora que conocemos el ordenamiento, podemos escribir nuestra propia función que convierta frames en imágenes de la clase IMAGE con el orden específico. La función queda

def frameToImage(frame):
  frame = (frame/255).astype(ct.c_float)
  me = np.hstack((frame[:, :, 2].flatten(), frame[:, :, 1].flatten(), frame[:, :, 0].flatten()))
  img = dn.IMAGE(frame.shape[1], frame.shape[0], 3, me.ctypes.data_as(ct.POINTER(ct.c_float)))
  return img

Necesitamos importar el paquete ctypes, que nos permite manipular tipos de C en Python. En la primera línea de la función, normalizamos cada elemento del frame de forma tal de que vaya de cero a uno y lo convertimos en un flotante de C. A continuación, queremos que todos los elementos estén en un a sola fila, así que tomamos todos los elementos de un color (por ejemplo, frame[:,:,2]), lo ponemos en una lista y removemos los paréntesis con flatten. Usando hstack creamos un vector que contiene todos los elementos en una misma fila, como queríamos. Queda algo como esto

 [z1 z2 z3 ... y1 y2 y3... x1 x2 x3...]

que es exactamente lo que necesitamos como entrada para IMAGE.

Finalmente, en la última línea, creamos una image class, así que le entregamos el ancho, la altura, un 3 que corresponde a la cantidad de colores y el vector que creamos antes, convertido en un puntero a flotante de C.

¡Al fin! Lo único que nos queda es reemplazar algunas pocas líneas en la función detect para cargar la imagen y estamos listos. Modificamos el archivo darknet.py, a partir de ahora contendrá nuestra función frameToImage y detect tomará un frame, llamará a nuestra función y la transformará en una clase de imagen por su propia cuenta. No tendrá salida ya que la usamos como una librería. La implementación entera está en el repositorio

Y finalmente, escribimos un script que ejecuta la función detect para cada frame de un video. Sólo necesitamos importar nuestra librería como import library as lib y llamar a la función detect como r = lib.detect(frame, meta, imagerot).

import numpy as np
import cv2 
import ctypes as ct
import math
import random
import libreria as lib

# Carga la red, los pesos y las etiquetas
net = lib.load_net(b"/home/user/darknet/cfg/yolov3.cfg", b"/home/user/darknet/yolov3.weights", 0)
meta = lib.load_meta(b"/home/user/darknet/cfg/coco.data")

# Lee el video y calcula el número total de frames 
video = cv2.VideoCapture("./video2.mp4")
number = int(video.get(cv2.CAP_PROP_FRAME_COUNT))

# Podemos definir desde qué frame y hasta cuál queremos ir acá (si queremos ir al último usamos ultimo = number)
primero = 0
ultimo = 10
currentframe = primero

print("\nDETECCION USANDO DARKNET + YOLOV3")
print(f"\nCantidad de frames totales = {number}")
print(f"\nPrimer frame = {primero}\nUltimo frame = {ultimo}")
print("\n\n" )

# Corre la red para los frames seleccionados
while currentframe < ultimo:

    video.set(1, currentframe)
    ret, framevid = video.read()
    print(currentframe)

    if ret: 
        imagerot = lib.rotateimage(framevid, 90) # Puede ser necesario rotar los frames del video
        r = lib.detect(net, meta, imagerot); # Procesado de la red
        print(r)
        print('###########################################################################')
    else: 
        break

    currentframe = currentframe + 1

# Libera el video
video.release()

Conclusiones

Este pequeño hack para poder utilizar darknet (con todo su poder) en Python junto a las herramientas de análisis de imágenes que ya conocemos (como openCV) nos permite simplificar mucho el reconocimiento de imágenes de alta performance con toda la versatilidad y las librerías de Python.
En adelante vamos a ver más en profundidad las capacidades extra que obtenemos al poder usar todas estas librerías.

Argumentos opcionales en Python: ¿por qué no hay que usar listas?

ninja-ia — Sun, 05 Jul 2020 13:30:34 +0000

Argumentos opcionales en Python: ¿por qué no hay que usar listas?

Imaginemos esta función (que, ustedes dirán, es bastante tonta) que agrega un elemento a una lista inicial, ambos argumentos de la función.
Pero además, queremos que por defecto, la lista inicial esté vacía, así que pasarle sólo un elemento a la función implique devolver una lista con únicamente ese elemento:

def agregar_a_lista(elemento, inicial=[]):
    inicial.append(elemento)
    return inicial

Así que vamos a usar nuestra humilde, pero correcta función!

>>> una_lista_larga = agregar_a_lista(5, [2, 3])
>>> print(una_lista_larga)
[2, 3, 5]
>>> una_lista_corta = agregar_a_lista(5)
>>> print(una_lista_corta)
[5]
>>> otra_lista_corta = agregar_a_lista(7)

Todo parece andar bien, y otra_lista_corta debería dar [7].
Sin embargo...

>>> print(otra_lista_corta)
[5, 7]

QUÉ!? ¿Qué pasó? ¿Se "acuerda" de que antes le había agregado un 5?

¿Cuándo se calculan los valores por defecto?

Esta es la primera pregunta que nos va a ayudar a entender lo que está sucediendo.
Para eso, vamos a usar: 1. el método __defaults__, que nos permite ver los valores por defecto de una función; y 2. el built-in id que nos devuelve una referencia única a cada objeto (es decir, dos objetos tienen el mismo id si y sólo si son el mismo objeto).
Ahora comenzamos de cero un

def agregar_a_lista(elemento, inicial=[]):
    inicial.append(elemento)
    return inicial


valores_por_defecto = agregar_a_lista.__defaults__
identidades = [id(valor) for valor in agregar_a_lista.__defaults__]
print(f"Valores por defecto: {valores_por_defecto}")
print(f"Identidades: {identidades}")

print("Ejecutando una_lista = agregar_a_lista(5)")
una_lista = agregar_a_lista(5)
print(f"Resultado: {una_lista}")

valores_por_defecto = agregar_a_lista.__defaults__
identidades = [id(valor) for valor in agregar_a_lista.__defaults__]
print(f"Valores por defecto: {valores_por_defecto}")
print(f"Identidades: {identidades}")

print("Ejecutando otra_lista = agregar_a_lista(7)")
otra_lista = agregar_a_lista(7)
print(f"Resultado: {otra_lista}")

Cuando ejecutamos ese script, obtenemos:

Valores por defecto: ([],)
Identidades: [140611099623168]
Ejecutando una_lista = agregar_a_lista(5)
Resultado: [5]
Valores por defecto: ([5],)
Identidades: [140611099623168]
Ejecutando otra_lista = agregar_a_lista(7)
Resultado: [5, 7]

Efectivamente, la función se acuerda de que le agregamos un 5, pero porque el objeto es el mismo (fíjense que las identidades concuerdan).
La primera vez que ejecutamos la función, modificamos su valor; entonces, la segunda vez que lo usamos, lo tomamos con el valor modificado.
La primera conclusión sería: no modifiquemos los valores por defecto dentro de una función de Python o, más general y más seguro, no usemos objetos mutables como valores por defecto en una función.

Bueno, pero ¿qué está pasando?

Como pueden ver, el __defaults__ de la función ya tiene un valor incluso antes de que la función se llame por primera vez.
Esto se debe a que los valores por defecto de la función se calculan cuando la función se define, no cuando se llama.
Este comportamiento se llama early-binding, y su contraparte (late-binding) calcula los valores por defecto en cada ejecución.

Podemos poner esto a prueba bastante fácilmente: ¿qué pasa si entre llamada y llamada volvemos a definir la función tal como estaba?

def agregar_a_lista(elemento, inicial=[]):
    inicial.append(elemento)
    return inicial


valores_por_defecto = agregar_a_lista.__defaults__
identidades = [id(valor) for valor in agregar_a_lista.__defaults__]
print(f"Valores por defecto: {valores_por_defecto}")
print(f"Identidades: {identidades}")

print("Ejecutando una_lista = agregar_a_lista(5)")
una_lista = agregar_a_lista(5)
print(f"Resultado: {una_lista}")


def agregar_a_lista(elemento, inicial=[]):
    inicial.append(elemento)
    return inicial

valores_por_defecto = agregar_a_lista.__defaults__
identidades = [id(valor) for valor in agregar_a_lista.__defaults__]
print(f"Valores por defecto: {valores_por_defecto}")
print(f"Identidades: {identidades}")

print("Ejecutando otra_lista = agregar_a_lista(7)")
otra_lista = agregar_a_lista(7)
print(f"Resultado: {otra_lista}")

Al ejecutar este script obtenemos el resultado esperado:

Valores por defecto: ([],)
Identidades: [140438619595200]
Ejecutando una_lista = agregar_a_lista(5)
Resultado: [5]
Valores por defecto: ([],)
Identidades: [140438619595840]
Ejecutando otra_lista = agregar_a_lista(7)
Resultado: [7]

No sólo los valores por defecto se vuelven a calcular, sino que además fíjense que tienen dos identidades distintas; es decir, son dos objetos distintos.

OK, entendido. Pero ¿cómo lo resuelvo?

La solución cuando no queremos este comportamiento (que es la mayoría de los casos) es utilizar lo que se llama un objeto centinela, para lo que generalmente se usa None:

def agregar_a_lista_bien(elemento, inicial=None):
    if inicial is None:
        inicial = []
    inicial.append(elemento)
    return inicial

Fíjense la diferencia cuando usamos esta función, comparándola con la anterior

una_lista = agregar_a_lista(5)
otra_lista = agregar_a_lista(7)
print(f"Identidades: {id(una_lista)}, {id(otra_lista)}")

una_lista_bien = agregar_a_lista_bien(5)
otra_lista_bien = agregar_a_lista_bien(7)
print(f"Identidades: {id(una_lista_bien)}, {id(otra_lista_bien)}")

Identidades: 139893270457152, 139893270457152
Identidades: 139893271721280, 139893270011200

En agregar_a_lista ambas listas son el mismo objeto (sus identidades son iguales), mientras que en agregar_a_lista_bien se crearon dos listas distintas: [5] y [7].
La diferencia fundamental es que el uso del valor centinela None nos permitió definir inicial dentro de la función y, así, es inicial = [] sucede cada vez que llamamos la función y no sólo al princiio como antes.

Algunas aclaraciones extra (quizás un poco más avanzadas)

Sobre los centinelas

No quiero ahondar mucho en este tema, pero hay veces que, en la función que usamos, el argumento por defecto podría ser None.
En ese caso, nuestra técnica del centinela interfiere con ese valor, porque lo considera simplemente el indicador de "acá va una lista vacía".
¿La solución? Usar centinelas únicos.
La explicación detallada quedará para más adelante, pero la idea es algo así:

_CENTINELA = object()

def agregar_a_lista_bien_unico(elemento, inicial=_CENTINELA):
    if inicial is _CENTINELA:
        inicial = []
    inicial.append(elemento)
    return inicial

Sobre el `is`

La keyword is en Python es para chequear identidades, no valores.
Es decir, A is B va a dar True si y sólo si id(A) == id(B); es decir, si y sólo si A y B son el mismo objeto.
¿Por qué comparamos con is y no con ==?
Porque en Python el comparador (==) se puede definir para cada clase a través del método __eq__; entonces, si creamos una clase que parece una lista, pero devuelve siempre True en las comparaciones:

class MiLista(list):
    def __eq__(self, other):
        return True

sucede:

>>> lista_prueba = MiLista([1, 2, 3, 4])
>>> lista_prueba == None
True
>>> lista_prueba is None
False

Así que nunca, nunca, nunca comparen valores centinela con ==.
Lo que me lleva al tercer y último punto:

Comparaciones implícitas

Python tiene conversiones implícitas de valores booleanos (True/False, bah).
Por ejemplo, las listas vacías, None y los números iguales a 0 se evalúan como False.
Así que, como None se evalúa a False, uno podría tentarse a escribir:

...
if not inicial:
    inicial = []

en vez del chequeo inicial is None.

A esto, además del problema de comparar con ==, se le suma que quizás sí quermeos pasar una lista vacía y modificarla (con un append), pero este código nos fuerza a crear una lista nueva inicial dentro del scope de la función.

Entonces...

Estudiar cómo funciona el lenguaje nos puede ayudar a que comportamientos que antes nos parecían raros se vuelvan más intuitivos.
En este caso en particular:

No usemos mutables como valores por defecto en Python.
None casi siempre es un buen valor centinela
Cuando no sirve como centinela, hay que arremangarse un poco; pero la lógica es la misma.
Los centinelas siempre se chequean con is, no con ==.

Excepciones en Python: No las estás usando lo suficiente

ninja-ia — Sun, 21 Jun 2020 18:51:27 +0000

¿Alguna vez estuviste googleando durante horas cómo "hacer que funcione" una librería?
¿Te preguntaste cómo hacer que tu código quede un poco más fácil de leer y de modificar?
¿Te interesaría conocer más acerca de técnicas utilizadas en IA?

Para responder estas preguntas y, por qué no, generar otras, es que desde Ninja quisimos abrir un nuevo espacio de comunicación.

Este artículo forma parte de una serie de conceptos que son, de cierta manera, periféricos a la Ciencia de Datos. Aprender estas cosas es necesario porque lo que vamos a ver en estos posts son conceptos bastante transversales a los proyectos que quieran hacer: permiten mejorar un poquito todos los códigos. Además, saber por qué se usan quizás nos ayude a entender mejor cuándo y por qué implementarlo.

Sin más introducciones, vamos ahora sí al tema que nos ocupa en este caso: las excepciones en Python.

¿Qué es "manejar los errores"?

Supongamos que alguien nos pide como tarea hacer una función que sume listas: es decir, dadas lista1 = [1, 2, 3] y lista2 = [10, 20, 30] nos devuelva [11, 22, 33].
Para resolver este problema, hacemos una función¹:

def sumar_listas(lista1, lista2):
    lista_total = []
    for i in range(len(lista1)):
        lista_total.append(lista1[i] + lista2[i])
    return lista_total

La probamos sobre nuestro ejemplo y 😍

>>> lista1 = [1, 2, 3]
>>> lista2 = [10, 20, 30]
>>> sumar_listas(lista1, lista2)
[11, 22, 33]

Pero en todas las historias hay un villano, y en este caso es alguien que quiere sumar la lista lista1 = [1, 2, 3] con lista2 = [10, 20, 30, 40] (es un villano bastante modesto²).
Nosotros sabemos que sumar eso no tiene sentido porque las listas no tienen el mismo tamaño, pero nuestra función no:

>>> lista1 = [1, 2, 3]
>>> lista2 = [10, 20, 30, 40]
>>> sumar_listas(lista1, lista2)
[11, 22, 33]

Queda claro que acá alguien está haciendo algo mal (nuestro villano) y nuestro programa no está preparado para lidiar con esto.
Pensamos una solución: como la suma de las listas tienen que ser una lista, podemos usar un entero como marca de que "algo anduvo mal".
Por ejemplo, si las listas son de distinto tamaño, devolvemos -1.
Entonces queda:

def sumar_listas_error(lista1, lista2):
    if len(lista1) != len(lista2):
        return -1
    lista_total = []
    for i in range(len(lista1)):
        lista_total.append(lista1[i] + lista2[i])
    return lista_total
>>> sumar_listas_error([1, 2, 3], [10, 20, 30])
[11, 22, 33]
>>> sumar_listas_error([1, 2, 3], [10, 20, 30, 40])
-1

Esta técnica que estamos usando es una implementación casera de manejo de errores, y no está nada mal.
Tiene algunas complicaciones y limitaciones, claro.
La primera es que tenemos que recordar que el -1 quiere decir que hubo un error.
Y la segunda es que éste no es el único error que se puede generar.
También seguramente queramos decir que hubo un error si tratamos de sumar listas con strings adentro: lista1 = ['uno', 2, 3] y lista2 = ['diez', 20, 30].
O sea que, con nuestra implementación casera, no sólo tenemos que chequear si está este error, sino además sería ideal elegir otro número (digamos -2) para avisar que el error es distinto.
Y hay que recordar qué significa ese número... y después elegir qué hacer si tenemos ese error!

Siempre es bueno tener un manejo de errores, y si eligen usar éste, ¡bienvenido sea!³
Es claramente mejor que nada.
Pero implica que tenemos que encargarnos nosotros como programadores de tres "problemas":

Recordar qué quieren decir -1, -2, etcétera.
Andar pasando el error de función en función. Además... ¿qué hacemos si -1 o -2 son resultados posibles de nuestra función?
Chequear a cada rato si la función tiró un error y decidir qué hacer.

Manejar errores de repente pone una montaña de cosas bajo nuestra responsabilidad.
En general, es mejor depender de soluciones usadas en la comunidad antes que crear la propia.
Hay una gran cantidad de motivos para justificar esto, algunos que todos tenemos presentes, otros que quizás no tanto.
Pero mejor que eso sea tarea de otro post.
Por lo pronto, en Python hay una forma mucho más linda, pensada desde el comienzo del lenguaje, que se comporta bien en todas las librerías.
En fin, más... Pythónica

El manejo de las excepciones de Python. Lanzar y capturar.

Obviando los errores de sintaxis (como por ejemplo olvidarse un : después de un if), Python maneja los errores a través de las excepciones.
Qué pasa por ejemplo, si tratamos de sumar un string con un int?

>>> '2' + 3
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot concatenate 'str' and 'int' objects

Ese TypeError que aparece ahí es una de las excepciones estándar de Python (tiene unas cuantas decenas) de las que veníamos hablando.
Esto resuelve el primer problema: es un error de Tipo.
Hasta escribe en pantalla (más o menos) cuál es el problema.
Ahora, para explicar cómo resuelve los otros dos problemas tenemos que cambiar la mentalidad.
Vamos a responder al problema 2 (cómo pasar el error de función en función) respondiendo a una pregunta similar: cómo hago para alertar al programa en general de un error.

Lanzar excepciones

Para esto, Python usa un carril paralelo al de los valores que devuelve en las funciones (fíjense que esto resuelve el bonus del problema 2.: qué hacer si nuestro código de error es un valor esperado por la función).
Imaginen que cada vez que ejecutamos una función nos metemos "un paso más abajo" en el código.
En este caso, la excepción frena todo y sube de golpe.
Este proceso de "alertar" se llama en la jerga lanzar una excepción y, en Python, se lanzan con raise.
En nuestro ejemplo de sumar_listas podemos pedir que cuando las listas tienen distinto tamaño, se lance la excepción ValueError (es una de las excepciones estándar de Python).
En ese caso, nuestra función se vería

def sumar_listas_lanza(lista1, lista2):
    if len(lista1) != len(lista2):
        raise ValueError("Las listas tienen distinto tamaño")
    lista_total = []
    for i in range(len(lista1)):
        lista_total.append(lista1[i] + lista2[i])
    return lista_total

y si ahí tratamos de sumar las listas que habíamos dicho antes, tenemos

>>> sumar_listas_lanza([1, 2, 3], [10, 20, 30, 40])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "sumar_listas.py", line 18, in sumar_listas_lanza
    raise ValueError("Las listas tienen distinto tamaño")
ValueError: Las listas tienen distinto tamaño

Fíjense que encima nos dice que el error está en sumar_listas_lanza, y hasta la línea del archivo! No podemos pedir mucho más.

Capturar excepciones

Bueno, quizás sí podemos pedir un poco más... ¿qué pasa si queremos hacer algo cuando hay un error?
Muy bueno lo del error y eso, pero quizás no quiero que cuando pase algo que no esperaba el programa se detenga por completo y se ponga a gritar ERROR ERROR.
Supongamos que quiero llamar a esta función, pero que si ambas listas son de distinto tamaño, directamente me devuelva la primera de ambas.
Una posibilidad sería que en vez del raise que pusimos adentro, pogamos un return de la lista por defecto... pero medio que estamos tirando todo por la borda.
Estábamos conformes con que fuera un error, simplemente queremos tratar de intervenir mientras va subiendo antes de que detenga todo el programa.
Además, en ese caso, la función no debería llamarse sumar_lista, sino sumar_lista_excepto_que_sean_de_distinto_tamano_etcétera (más allá del nombre, la función ya no sólo "sumaría dos listas").

Lo que tenemos que hacer es capturar la excepción.
El ejemplo se ve más claro si imagináramos que una función está llamado a nuestro sumar_listas_lanza y, con el resultado, hace algo.
Por ejemplo, la función maximo_suma que ponemos aquí devuelve el máximo de la suma de las listas.

def maximo_suma(lista1, lista2):
    suma = sumar_listas_lanza(lista1, lista2)
    maximo = max(suma)
    return maximo

Las excepciones se capturan con los bloques de try/except.
Como casi todo lo que está desarrollado en Python, se puede tratar de "leer" directamente: quiere decir intentá X, excepto que pase Y.
Nosotros podríamos intentar sumar_listas_lanza, excepto que haya un ValueError y, en ese caso, usamos la primera lista, lista1:

def maximo_suma(lista1, lista2):
    try:
        resultado = sumar_listas_lanza(lista1, lista2)
    except ValueError:
        resultado = lista1
    maximo = max(resultado)
    return maximo

En conclusión

Tener un sistema de manejo de errores es importante, y Python nos permite que las excepciones vayan por un carril separado a las funciones.
Aprovechando eso, los códigos quedan mucho más claros, tanto al leerlos como al ejecutarlos.
En la próxima edición, vamos a ver cómo usar las excepciones de Python para controlar el flujo de ejecución y cómo crear nuestras propias excepciones.

El código que escribimos aquí no va a ser 100% "pythonico" (más de uno podría poner el grito en el cielo porque usemos for i in range(len(a))); pero priorizamos que se entienda el concepto. ↩
Está bueno pensar siempre en cómo se comporta nuestro código fuera del comportamiento que teníamos en mente; la técnica de pensar que estamos programando para evitar que un "villano" haga que nuestro código dé resultados incoherentes es bastante útil. ↩
De hecho, es parecido al que usa nada menos que el kernel de Linux. Claro, no tienen muchas más alternativas. ↩

DEV Community: ninja-ia

¿Cuánto tarda un borracho en ganar al Pacman?

El Pacman

Avanzar una posición

Terminó el mapa

Bonus: __str__

Resultados

Dependencia con el tamaño

Ahora sí, ¿cuánto tarda el borracho?

Y ahora, ¿qué?

Detección en YOLO, frame por frame

Nuestra función

Conclusiones

Argumentos opcionales en Python: ¿por qué no hay que usar listas?

Argumentos opcionales en Python: ¿por qué no hay que usar listas?

¿Cuándo se calculan los valores por defecto?

Bueno, pero ¿qué está pasando?

OK, entendido. Pero ¿cómo lo resuelvo?

Algunas aclaraciones extra (quizás un poco más avanzadas)

Sobre los centinelas

Sobre el is

Comparaciones implícitas

Entonces...

Excepciones en Python: No las estás usando lo suficiente

¿Qué es "manejar los errores"?

El manejo de las excepciones de Python. Lanzar y capturar.

Lanzar excepciones

Capturar excepciones

En conclusión

Bonus: `str`

Sobre el `is`