Bueno pues aqui voy con mi particular acercamiento al snippet de @thinbaker con la librería Pillow.
Claro que como ya adelanté, yo he integrado el código del tocayo en mi herramientilla/playground de python #Python
Ya dije q suelo iterar sobre un concepto en cada oportunidad. Como veis hay un fichero principal y una "carga de pago" consistente en uno o varios comandos como modulos independientes...
En este caso hay tres snippets sacados de Twitter integrados en la misma herramienta..
El modulo main se encarga de preparar la estrutura de argparse, aumentarla con "subparsers" para cada comando que se añada y de comprobar la cmdline y bifurcar al comando apropiado... Es casi lo mismo que visteis para el #AdventOfCode
En este caso el comando PNG2ascii está implementado en el modulo commands/png2ascii.py en incluye el subparser que se encarga de las necesidades propias de este comando..
El "main" a peticion del parser que veis arriba "sabe" que el comando en si está implementado en la función command a la cual se pasa el objeto Namespace que contiene los switches y rutas a ficheros que se hayan encontrado en la liena de comandos..
Una vez sabemos el fichero PNG lo abrimos, le tomamos medidas y convertimos cada pixel en un char, a la manera que hizo @thinbaker. Finalmente concatenamos el resultado en ascii_art
Si el bloque "Try" fué bien podemos bien imprimir por consola el resultado o escribirlo en un fichero cuestion que resolvemos mirando si existe args.output en caso de que el usuario solicitó escribir la salida a un fichero...
Yo no soy de Pokemons asi que permitidme que use el típico ejemplo de PNG sacado de la wiki:
Bien y como usamos la herramienta? Bueno, pues argparse se encarga de mostrarnos la ayuda principal y la ayuda de cada comando, cosa de la que nos aprovechamos inmediatamente..
Ejecutamos la herramienta y vereis el Loro convertido en ASCII (he partido la salida en dos) de igual manera que @thinbaker nos enseño con sus Pokemons..
Y ahora veamos el funcionamiento con el switch opcional "--output" Seguidamente abrimos el fichero en el propio @vcode y vemos que el resultado es correcto.
Bueno hasta aqui mi versión del código de @thinbaker en la que he tratado de preservar la parte uya con los cambios mínimos de CV2 a Pillow
Estaba leyendo sobre ASCII Art y dithering y se me ha ocurrido que el código sólo funciona para imágenes RGB por lo que he hecho los preparativos para poder jugar con otros formatos...
Primero segregamos el codigo de @thinbaker version Pillow en una función separada..
Despues he usado un salto con diccionario (que tanto le gustan a @Josheriff ) por lo que para poder procesar diferentes formatos (de los que soporta PiIllow claro!) usaremos nuevas funciones que añadiremos al diccionario.
Bueno pues estoy leyendo: publications.lib.chalmers.se/records/fullte…
asi que quizas me anime a ver si puedo codificar lo que proponen, y si quiero usar a "Lena" deberemos soportar el formato "L" escala de grises probablemente..
Bueno en realidad no sé que complicado es esto de codificar pero lo pongo igualmente por que se que a @thinbaker y a @Chucheria les molan mucho estas cosas..
Saludos!
Y si os preguntais para que vale esto:
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Este el el punto de partida para la mas interesante: continuacion delimitada (algo que GHC está en proceso de tener como operación nativa), tambien en la wiki:
Muchos perros en la epoca navideña lo pasan mal con los petardos. Triste pero por otro lado una de las situaciones en la que el dueño de una mascota sufre una imposición por parte de un tercero. +
Aun recuerdo el mordisco que me dío en la pantorilla un perrete "juguetón" y la cara de sus dueñas incapaces de gesticular mas allá de un "perdon! solo quería jugar"
Como si el poder llevarse un bocado fuera una decisión colegiada con cualquier viandante que se cruzasen... +
Como yo tuve perro puedo empatizar con ambos lados pero a mi personalmente me queda claro la unidireccionalidad que se dá en estas situaciones.
Las personas con mascotas las "imponen" a las demás. Es como el fumar: tu fumas, yo me trago tus humos, no hay reciprocidad posible. +
Atribuyen a Edison la frase: “I will not say I failed 1000 times, I will say that I discovered there are 1000 ways that can cause failure.” Pues yo he estado haciendo lo mismo en los ratos libres de estos ajetreados días... +
Por las noches mientras veía alguna peli del Prime time he estado programando mi particular acercamiento al problema 15 haciendo stiching de soluciones para encontrar la solución completa al #AoC +
La dificultad no provenía del Floyd Warshall sino de como pegar las soluciones entre si propagando los costos del tal manera que no me sorprendian los fallos, hasta que aburrido/estancado pensé programar el dijkstra para tener la solución y comparar el devenir de cada código.. +
El parser: secuencia de parsers "polymerP" y "newlineP >> rulesP" que capturan tanto la plantilla como las reglas. Creamos todos los subparser necesarios. Leed la función desde el final hacia arriba y veréis la "estructura"
la parte 1 "del tirón". Leemos las reglas y preparamos un diccionario.. BB -> C. En cada paso de polimerización convertimos el pólimero en pares(zip) y aplicamos la conversión a cada par según el dict. El resultado crece rápidamente por lo que abreviamos la salida si len > 60
El parser como siempre: construimos partes como número, coordenada etc.. Aquí la novedad es instructionP que parsea un "fold" y devuelve un lambda que realiza el doblado propiamente dicho "lambda a: fold(a, x, y)" donde x y son el eje e y la fila ó columna respectivamente.
para construir la hoja desde las coordenadas suminstradas tenemos la función data_to_sheet bastante directa (reseñar que hay que averiguar primero la dimensión de las lista de listas)
Preparamos un diccionario con las conexiones entre nodos (si a -> b entonces b -> a tambien) y luego llamamos a la función traverse que devuelve un generador de rutas que usamos para contabilizar la respuesta y mostrar las rutas al asuario.