funcionamiento de la generación de claves TOTP

Tue, 26 Dec 2023 05:43:42 GMT

Cada vez es mas común que la mayoría de sitios web te pidan activar la verificación de dos factores mediante el uso de claves OTP (Contraseñas de un solo uso).
Su uso es realmente simple: el servicio en donde quieres activar dicha característica te proporciona una clave alfanumérica, ya sea en texto plano o mediante un código QR, y tu la introduces en un software que te sirva como llavero de ese tipo de claves (Authy, 1Password, Aegis, Vualtwarden, etc...), y listo. Cada que quieres iniciar sesión en la web, a parte del usuario y la contraseña, también deberás introducir el código de 6 dígitos que te genera en tiempo real tu llavero.</p>

El algoritmo detrás de TOTP es bastante simple ya que solo necesita 2 datos para generarte la clave de 6 dígitos y es:</p>

Una llave alfanumérica</li>

La fecha y hora actual en UTC</li> </ul>
Teniendo esos 2 datos realmente podrías calcular en un papel tu contraseña de un solo uso (aunque para cuando termines, ya habrán pasado 30 segundos y ya no funcionaría jeje).</p>
Voy a dividir el proceso en varios pasos para que se pueda entender mejor.</p>
Preprocesar los datos</h2>
Primero que nada la fecha debemos pasarla de un formato como 12-Dic-2023 14:04:03</code> a su Unix Epoch</a>, que es la cantidad de segundos que han pasado desde el 1/Enero/1970 hasta la fecha seleccionada. Así pues, el Unix Epoch de la fecha anterior luce algo como 1702411443</code>. Una vez que ya tienes la fecha en ese formato, ahora debes dividirlo por el intervalo de tiempo que necesites que se refresque la clave. Lo estándar suele ser 30 segundos. Así que tomando el ejemplo anterior quedaría de la siguiente manera 1702411443 / 30 = 56747048</code>. Solo nos interesa la parte de los enteros, los decimales los puedes descartar. Teniendo ya ese número, el último paso es sacar los bytes en formato Big Endian</a>. En Python se puede hacer con el método int.to_bytes</code>:</p>
msg = 56747048 bytes_msg = msg.to_bytes(8, byteorder="big") print(list(bytes_msg)) # [3, 97, 228, 40] </code></pre> Como primer parámetro le pasamos la longitud de bytes del número y como segundo parámetro en que Endianidad</a> los queremos.</p> La siguiente tarea es decodificar la clave que nos dieron en la web, ya que todas las páginas la dan en formato Base32</a> para que sea mas sencillo copiar en texto plano o dictarla. Esto con ayuda de alguna web o biblioteca de Python se puede hacer fácil.</p> from base64 import b32decode TOTP_KEY = "BOMY6BV5BWVJEWJ4ZLDYKN3LSIS736B3" # Clave de ejemplo key_decoded = b32decode(TOTP_KEY, casefold=True) print(list(key_decoded)) # [11, 153, 143, 6, 189, ..., 248, 59] </code></pre> A partir de este punto a la fecha ya procesada le voy a llamar "mensaje" y a la clave ya decodificada le voy a llamar "llave", para evitar confusiones futuras. Teniendo ya nuestros datos procesados, ahora si vamos a la generación de la clave como tal.</p> HMAC-SHA1</h2> HMAC es un algoritmo que fue pensado con el propósito de tener un método robusto y flexible para validar mensajes en combinación con un llave secreta. HMAC puede utilizarse con una multitud de algoritmos Hash</a> y TOTP utilizar SHA1 como algoritmo de Hasheo. Esto en principio podría parecer inseguro, ya que SHA1 es un algoritmo que se podría considerar obsoleto para guardar contraseñas, pero TOTP no utiliza a SHA1 para generar un hash para almacenarlo, solo lo usa para generar una clave que a lo mucho servirá por un intervalo corto de tiempo y luego será inútil. Además, SHA1 es bastante mas barato de computar que otros competidores como SHA-3, SHA-256, Tiger, Etc... La forma de calcularlo es un poco compleja de entender, pero por fortuna no tiene tantos pasos.</p> Los pasos que vamos a seguir son los siguientes:</p> Primero generamos un Array de 64 elementos, primero irán los elementos de nuestra llave y, en caso de que no se llenen todos los campos, rellenamos con ceros a la derecha. Lo llamaremos key_pad</code>.</li> </ul> # Indice 0 1 2 3 4 19 20 21 22 62 63 key_pad = [11, 153, 143, 6, 189, ..., 248, 59, 0, 0, ..., 0, 0] </code></pre> A partir de ese Array, creamos otro con todos los elementos del anterior pero aplicando un XOR</a> con el número 0x36</code>. A este nuevo grupo de bytes lo llamamos i_key_pad</code>.</li> </ul> i_key_pad = bytes(x ^ 0x36 for x in key_pad) </code></pre> Repetimos el paso anterior pero aplicando el XOR con el número 0x5C</code> y a este otro grupo de bytes será el o_key_pad</code>.</li> </ul> o_key_pad = bytes(x ^ 0x5C for x in key_pad) </code></pre> Concatenamos el i_key_pad</code> con los valores de nuestro mensaje.</li> </ul> i_key_pad_msg = i_key_pad + msg </code></pre> Lo que resulte lo pasamos por nuestra función de Hasheo (SHA1 en nuestro caso).</li> </ul> i_key_pad_msg_hashed = hashlib.sha1(i_key_pad_msg).digest() </code></pre> Concatenamos lo que resulte del paso anterior con lo que tenemos en o_key_pad</code>.</li> </ul> o_key_pad_msg = o_key_pad + i_key_pad_msg_hashed </code></pre> Y como último paso, tambien hasheamos lo que haya resultado del paso anterior.</li> </ul> hmac_result = hashlib.sha1(o_key_pad_msg).digest() </code></pre> La razón del uso de los números 0x5C</code> y 0x36</code> no está del todo clara para mi. Según vi que era por que esos números son especialmente buenos para ofuscar y generan un patrón único que mejora la seguridad... esto no lo puedo asegurar, pero apuesto a que las personas que trabajaron en el diseño del algoritmo saben infinitas veces mas que yo sobre criptografía, así que solo nos queda confiar.</p> Una vez sacado el resultado del HMAC, ahora si vamos a generar nuestra bonita clave TOTP.</p> Algoritmo TOTP</h2> Esta última parte también es una locura de cosas que parecen meramente elegidas al azar pero ya son los últimos pasos antes de tener nuestra preciada clave TOTP, así que vamos a continuar. Los pasos a seguir son:</p> Tomar el valor en la posición 20 de los bytes que obtuvimos con HMAC y de ese valor, obtener los primeros 4 bits. Esto último lo podemos hacer utilizando el operador AND</a> con el número 0xF</code> (una explicación mas detallada acerca se encuentra al pie de página).</li> </ul> hmac_result = ... start = hmac_result[19] & 0xF </code></pre> Ahora utilizamos ese número como índice inicial y tomamos los siguientes 4 valores.</li> </ul> raw_bytes = hmac_result[start:start + 4] </code></pre> Ahora generamos un número entero utilizando esos 4 bytes en formato Big Endian.</li> </ul> raw_token = int.from_bytes(raw_bytes, byteorder="big") </code></pre> Ahora a ese valor le aplicamos la máscara 0x7FFFFFFF</code> de vuelta con el operador AND.</li> </ul> raw_token = raw_token & 0x7F_FF_FF_FF </code></pre> Y como último paso debemos saber cual es el número de dígitos que debe tener nuestro token TOTP. Lo mas común es que sean 6 pero podría variar dependiendo del servicio web. Conociendo eso ahora le aplicamos el operador MOD</a> con un número con esa cantidad de 0's en la izquierda y un 1 a la derecha. Por ejemplo con 6 dígitos sería 1_000_000</code>.</li> </ul> token = raw_token % 1_000_000 </code></pre> Y ¡¡listo!!, ese token ya lo podríamos introducir en el campo donde nos pide la clave de doble autenticación.</p> Parece un mecanismo algo retorcido, pero es de hecho bastante ingenioso ya que la generación de clave se hace utilizando únicamente la fecha y hora actual y la llave que nos da la web en donde queremos autenticarnos y este proceso es completamente offline y totalmente en local. Una prueba de ello es el proyecto en el que cree un llavero de claves TOTP con un Arduino, una pantalla LCD y un RTC. En mi Mastodon</a> esta el proyecto, por si gustan verlo.</p> También aquí dejo una implementación, tanto en Python</a> como en Rust</a> de lo presentado en este artículo.</p> Explicación sobre filtrar bits con el operador AND</h3> El operador AND se emplea para filtrar bits de un número aplicándole una máscara. Por ejemplo, consideremos el número 219 = 0b11011011</code>, y si solo nos interesan los primeros 4 bits, aplicamos una máscara con 4 bits activos 0b1111 = 0xF</code>. Al utilizar el operador AND, obtenemos 0b11011011 & 0xF = 0b1011</code>.</p> Para comprender mejor la operación, observemos la tabla de verdad del operador AND:</p> A</th> B</th> &</th> </tr> </thead> 1</td> 1</td> 1</td> </tr> 1</td> 0</td> 0</td> </tr> 0</td> 1</td> 0</td> </tr> 0</td> 0</td> 0</td> </tr> </tbody> </table> Y viendo la operación en una tabla se puede apreciar mejor como, efectivamente, solo se están conservando los bits del número inicial en donde la máscara tiene 1's.</p> </th> 7</th> 6</th> 5</th> 4</th> 3</th> 2</th> 1</th> 0</th> Decimal</th> Hexadecimal</th> </tr> </thead> Valor</td> 1</td> 1</td> 0</td> 1</td> 1</td> 0</td> 1</td> 1</td> 219</td> 0xDB</td> </tr> Máscara</td> 0</td> 0</td> 0</td> 0</td> 1</td> 1</td> 1</td> 1</td> 15</td> 0xF</td> </tr> Resultado</td> 0</td> 0</td> 0</td> 0</td> 1</td> 0</td> 1</td> 1</td> 11</td> 0xB</td> </tr> </tbody> </table> Notas</h3> En este artículo expliqué una versión simplificada de HMAC-SHA1. La versión completa del algoritmo HMAC toma en cuenta la longitud de la llave y, sí es mayor a 64, le aplica un SHA1 y utiliza ese resultado como nueva llave. Sin embargo, dado que para generar claves TOTP las llaves raramente superan esa longitud, decidí omitir ese detalle para simplificar la explicación.</p> Fuentes y enlaces de interés</h3> Especificación de HMAC RFC-2104</a></li> Especificación de TOTP RFC-6238</a></li> https://es.wikipedia.org/wiki/HMAC</a></li> https://github.com/jedisct1/rust-hmac-sha1/blob/master/src/lib.rs</a></li> https://github.com/pyauth/pyotp</a></li> </ol> Rust en Arduino - La manera difícil Thu, 22 Dec 2022 06:44:14 GMT Vamos a realizar el ejemplo mas sencillo que puede existir en Arduino, como el “hola mundo” para el área de embebidos, un led que parpadea.</p> Antes de empezar necesitamos adecuar nuestro ambiente de trabajo y para ello se necesitarán 3 cosas:</p> avr-gcc Herramientas de compilación para la arquitectura del procesador</li> </ul> </li> avr-binutils Herramientas para manipulación del resultado de compilación</li> </ul> </li> avrdude Para subir al Arduino el resultado de nuestra compilación desde linea de comandos</li> </ul> </li> avr-atmel328p.json</a> Es un archivo que contiene info relevante para la compilación, como la ubicación del linker, del compilador, el endianness</a>, etc...</li> </ul> </li> </ul> Para este texto yo estaré utilizando mi distro de Arch con los paquetes avr-gcc avr-binutils avr-libc avrdude</code> instalados, ustedes pueden ver como instalarlos en su distro o en el sistema operativo de su elección... Desconozco cual es el procedimiento para hacerlo en Windows, pero siempre se puede utilizar el WSL y yo digo que debería ir bien, pero no lo he probado.</p> Notación numérica</h2> Antes de comenzar voy a explicar la notación numérica que estaré utilizando. Sí un número comienza con 0x</strong> Significa que ese número está siendo expresado en hexadecimal. De otra forma, si comienza con 0b</strong> indica que ese numero está siendo escrito en binario. Sí de lo contrario, no contiene ningún prefijo, es que ese número está en decimal.</p> Prefijo</th> Sistema</th> Ejemplo</th> </tr> </thead> 0x</strong></td> Hexadecimal</td> 0x</strong>25 = 37</td> </tr> </td> </td> 0x</strong>FF = 255</td> </tr> 0b</strong></td> Binario</td> 0b</strong>101 = 5</td> </tr> </td> </td> 0b</strong>1010101 = 85 = 0x55</td> </tr> </td> </td> 0b</strong>11111111 = 255 = 0xFF</td> </tr> «Nada»</td> Decimal</td> 10, 5, 240</td> </tr> </tbody> </table> Si quieres convertir entre los distintos sistemas puedes utilizar a Python con las funciones bin</code> y hex</code>, que reciben un número y lo convierten a binario o hexadecimal respectivamente.</p> Registros</h2> Lo primero que deben de hacer es… olvidar todo lo que saben hasta ahorita de Arduino, por lo menos sí solo haz programado Arduinos con Processing, que es el lenguaje por defecto del Arduino IDE.</p> Recuerdan esos numeritos a los lados de los pines en tu Arduino?</p> +-----+ +----[PWR]-------------------| USB |--+ | +-----+ | | GND/RST2 [ ][ ] | | MOSI2/SCK2 [ ][ ] A5/SCL[ ] | | 5V/MISO2 [ ][ ] A4/SDA[ ] | | AREF[ ] | | GND[ ] | | [ ]N/C SCK/13</b>[ ] | | [ ]IOREF MISO/12</b>[ ] | | [ ]RST MOSI/11</b>[ ]~| | [ ]3V3 +---+ 10</b>[ ]~| | [ ]5v -| A |- 9</b>[ ]~| | [ ]GND -| R |- 8</b>[ ] | | [ ]GND -| D |- | | [ ]Vin -| U |- 7</b>[ ] | | -| I |- 6</b>[ ]~| | [ ]A0</b> -| N |- 5</b>[ ]~| | [ ]A1</b> -| O |- 4</b>[ ] | | [ ]A2</b> +---+ INT1/3</b>[ ]~| | [ ]A3</b> INT0/2</b>[ ] | | [ ]A4</b>/SDA RST SCK MISO TX►1</b>[ ] | | [ ]A5</b>/SCL [ ] [ ] [ ] RX◄0</b>[ ] | | [ ] [ ] [ ] | | UNO_R3 GND MOSI 5V ____________/ \_______________________/ </pre> Pues olvídense de ellos, ya que ahora les presentare los registros.</p> Los registros son áreas de la memoria de un procesador y su función es guardar o leer información y cada registro tiene un identificador numérico único, comúnmente expresado en hexadecimal.</p> Lo curioso es que la información no solo puede ser escrita por el procesador, sino que, sensores y otros chips externos al circuito principal también pueden leer y modificar esos registros. En términos prácticos, es lo que modificamos cuando escribimos un digitalWrite y es de donde obtenemos la información cuando ejecutamos un digitalRead en processing.</p> Dicho esto, en el Arduino UNO podemos identificar físicamente, por así decirlo, 4 secciones distintas de pines:</p> La primera, es la sección que tiene todo lo relacionado a la alimentación de la placa como tal.</li> La segunda es la sección donde se encuentran los pines compatibles con salidas analógicas, son los que tienen grabado antes del nombre del Pin una letra “A”.</li> La tercera podríamos llamarla “pines generales: primera sección”, que comprenden los pines marcados en el PCB desde el 0 hasta el 7.</li> y la cuarta y ultima es la sección “pines generales: segunda sección”, que comprende desde el Pin marcado como 8 hasta el 13.</li> </ul> +-----+ +----[PWR]-------------------| USB |--+ | +-----+ | | GND/RST2 [ ][ ] | | MOSI2/SCK2 [ ][ ] A5/SCL[ ] | ═══╗ | 5V/MISO2 [ ][ ] A4/SDA[ ] | ║ | AREF[ ] | ║ | GND[ ] | ║ ╔═══ | [ ]N/C SCK/13[ ] | Sección ║ | [ ]IOREF MISO/12[ ] | 4 ║ | [ ]RST MOSI/11[ ]~| ║ Sección | [ ]3V3 +---+ 10[ ]~| ║ 1 | [ ]5v -| A |- 9[ ]~| ║ ║ | [ ]GND -| R |- 8[ ] | ═══╝ ║ | [ ]GND -| D |- | ╚═══ | [ ]Vin -| U |- 7[ ] | ═══╗ | -| I |- 6[ ]~| ║ ╔═══ | [ ]A0 -| N |- 5[ ]~| ║ ║ | [ ]A1 -| O |- 4[ ] | Sección Sección | [ ]A2 +---+ INT1/3[ ]~| 3 2 | [ ]A3 INT0/2[ ] | ║ ║ | [ ]A4/SDA RST SCK MISO TX►1[ ] | ║ ╚═══ | [ ]A5/SCL [ ] [ ] [ ] RX◄0[ ] | ═══╝ | [ ] [ ] [ ] | | UNO_R3 GND MOSI 5V ____________/ \_______________________/ </code></pre> Las secciones en donde nos vamos a centrar aquí serán las 3 ultimas.</p> Cada sección de pines tiene asignado 3 registros, uno que contendrá el modo en el que se encuentra cada Pin, otro contiene los valores de salida y otro con los valores de entrada.</p> Cada registro en el Arduino UNO es de 8 bits y cada bit en ese entero u8</code> va a ser capaz de manipular independientemente un Pin. Creo que con un ejemplo lo vamos a entender mejor.</p> Para mayor facilidad en este ejemplo voy a hacer este ejercicio con el 3er grupo de pines, los marcados desde el 0 hasta el 7.</p> Como había dicho anteriormente, cada grupo de pines tiene 3 registros asignados, uno que indica si el pin es de lectura o escritura y otro que trae la info. Bien, entonces digamos que el grupo 3 tiene asignados los siguientes registros: AA - para controlar el modo AB - para escribir valores de salida AC - para leer los valores de entrada</p> Cada bit del u8 corresponde a un Pin físico de nuestro Arduino. Comencemos con el registro AA, que es el que controla los modos.</p> 8 7 6 5 4 3 2 1 AA = [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] -------------------------------------- [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] \ 7 6 5 4 3 2 1 0 | TX RX | </code></pre> Digamos que si le escribimos un 1 en algún bit del registro AA (el de modos), pondremos ese pin en modo de OUTPUT y por lo contrario, si le colocamos un 0, se pondrá en modo INPUT. entonces haciendo un:</p> 8 7 6 5 4 3 2 1 AA = [0] [0] [0] [0] [1] [1] [1] [1] = 0x0F = 15 -------------------------------------- [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] \ 7 6 5 4 3 2 1 0 | TX RX | </code></pre> Eso colocaría al PIN 1,2,3,4 en modo OUTPUT y el 5,6,7,8 en modo INPUT.</p> Ya que controlamos mas o menos esta información, ahora sigue el siguiente registro. Nuestro registro hipotético AB sería el encargado de almacenar la información de salida de los pines. Sí el Pin está en modo OUTPUT y de manera interna colocas un 1, el Pin mandaría voltaje alto (5v).</p> 8 7 6 5 4 3 2 1 AA = [0] [0] [0] [0] [0] [0] [0] [1] = 0x01 = 1 -------------------------------------- [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] \ 7 6 5 4 3 2 1 0 | TX RX | </code></pre> Si colocamos el valor 0b00000001 = 0x01 = 1, esto haría que el actuador que tengamos conectado al Pin marcado como 0 en el PCB, se active.</p> Y el último registro, el AC, se puede intuir mas o menos como se va a comportar, sí el pin está en modo INPUT, y con algún sensor se le mande voltaje alto, este colocaría el bit correspondiente al Pin en 1 (Al final del post hay una nota con respecto a esto).</p> Ok, perfecto, ya sabemos como gestionar el modo y la info de los pines desde los registros... pero como se manipulan o leen esos registros desde Rust?</p> Esqueleto del main.rs</h2> Para hacer que Rust pueda compilar a un Arduino se necesita un archivo main.rs</code> algo parecido a esto:</p> #![no_std] #![no_main] #[no_mangle] pub extern "C" fn main() {} #[panic_handler] fn panic(_info: &::core::panic::PanicInfo) -> ! { loop {} } </code></pre> Y lo iré explicando linea a linea.</p> #![no_std] #![no_main] </code></pre> Estas primeras lineas contienen unos macros que le indican al compilar de Rust 2 cosas:</p> No incluyan la biblioteca estándar a este proyecto</li> Este proyecto no tendrá una función main "rustificada". Este ultimo punto significa que vas a deslindar al compilador de asignar un punto de entrada a tu programa, esa chamba te la estás delegando a ti y sí tu programa no sabe por donde arrancar, el compilador se lavará las manos.</li> </ol> #[no_mangle] pub fn extern "C" main() { } </code></pre> El macro encima de la función main</code> con muchas cositas extra, le está indicando al compilador que no haga optimizaciones de nombres. Y es que Rust (y muchos otros lenguajes como C++, D, etc...), al momento de compilar, les da igual el nombre que tu le hayas colocado a tu función, internamente se llamará de otra forma. En programas clásicos eso da igual, mientras todo funcione como tenga que funcionar, a tu realmente te da igual que la función se llame "main" o punto_de_entrada_asbdauhsd123</code>, mientras el programa comience por ahí, está todo bien.</p> Sin #[no_mangle]</code> https://godbolt.org/z/boT6aKobf</a></li> </ul> Rust</th> Ensamblador</th> </tr> </thead> pub fn square(num: i32) -> i32 { num * num }</pre></td> _ZN7example6square17h6dfd88b0be9f1c7eE:</b> push rax imul edi, edi mov dword ptr [rsp + 4], edi ...</pre></td> </tr> </tbody> </table> Con #[no_mangle]</code> https://godbolt.org/z/W8oe95nar</a></li> </ul> Rust</th> Ensamblador</th> </tr> </thead> #[no_mangle] pub fn square</b>(num: i32) -> i32 { num * num }</pre></td> square:</b> push rax imul edi, edi mov dword ptr [rsp + 4], edi ...</pre></td> </tr> </tbody> </table> (En estos ejemplos se está utilizando el "pub" para que jale en godbolt, pueden ignorarlos sin problemas)</p> Peeeeero, recuerden que el trabajo de asignar un punto de entrada al programa se la quitamos al compilador, así que la persona que está programando es la que se debe aventar esa chamba y es justo lo que haremos a continuación. La segunda linea, esa que tiene un montón de cositas extras en la función main</code> significan:</p> pub</code>: Le estás indicando al compilador que la función main</code> puede ser llamada por fuera del archivo main.rs</code> que la contiene, ya que de otra manera, esa función solo podría ser accedida desde el propio archivo.</li> extern "C" main</code>: Le estamos indicando al compilador que el ABI que utilizará esa función es el de "C". Esto es un poco mas complejo de explicar, pero digamos que existen varias formas de llamar a una función y cada lenguaje tiene la suya. Pero para comunicarse entre lenguajes necesitan un mediador o "especificación en común" y ahí es donde entra el ABI de C y básicamente es la forma en la que esa función debe ser llamada (ir a la lista de enlaces para mas información acerca de esto, por sí les interesa).</li> </ul> #[panic_handler] fn panic(_info: &::core::panic::PanicInfo) -> ! { loop {} } </code></pre> Visto lo anterior, esto es muuucho mas sencillo de entender. Vamos línea por línea:</p> El macro panic_handler</code> le indica al compilar que deberá llamar a la función que se encuentra debajo cada que ocurra un panic</code>.</li> fn panic</code> core::panic::PanicInfo</code>: Contiene la información del panic</code>, la linea que lo causó, el mensaje de error, el traza del error, etc...</li> -> !</code>: Esto le está indicando al compilador que esa función nunca va a terminar ya que tiene un loop infinito sin condición de salida. Se puede prescindir de ello, pero ya que existe la función de indicar algo tan especifico al compilador, pues se lo ponemos.</li> </ol> </li> loop {}</code>: Es un loop infinito sin condición de salida.</li> </ol> Y a grandes rasgos significa qué cuando nuestro programa tenga un panic!</code>, lo que hará será ejecutar un loop infinito y tendremos que reiniciar a mano nuestro Arduino. Ya existen crates que tienen implementadas varias entradas en pánico (Consultar las referencias la final del documento), pero quería enseñarles que también se pueden implementar las propias.</p> También necesitaremos tunear un poco el Cargo.toml agregando esto al final:</p> [profile.release] lto = true panic = "abort" </code></pre> Y es básicamente un workaround para que todo el conjunto compile, ya que la arquitectura AVR no está soportada oficialmente por el equipo de Rust, puede que algunos cambios rompan la compatibilidad.</p> El primero es la optimización del linker... esto no sería necesario, pero actualmente existe un bug con ciertas versiones de LLVM que impiden que el programa compile, y se puede evitar habilitando esa optimización.</li> panic = "abort"</code>: Aquí vamos con un concepto algo complicado... Cuando tu programa en Rust tiene un panic</code>, por defecto comienza a desalojar la información que existía en el stack de atrás hacía adelante, el "cómo" suele venir en la biblioteca estándar, ya que puede variar entre arquitecturas y entre OS's. Pero aquí como no tenemos std, pues nos tocaría hacer a mano esa liberación de memoria, peeero como pues nuestro panic es un maldito loop vacío, pues nos da igual sí el stack se queda con cosas o no. el "abort" indica que deje todo como está y vaya al panic_handler</code> directamente (ver el lang_item = "eh_personality" para mas info al respecto).</li> </ol> Y ¡¡Listo!!, ya con ese main.rs</code> y Cargo.toml</code> está todo listo para compilar tu hermoso primer ejemplo con la siguiente linea:</p> cargo build -Z build-std=core --target avr-atmega328p.json --release </code></pre> Cada parámetro significa lo siguiente:</p> -Z build-std=core</code>: Sin esta linea, Cargo no agregará el crate "core". Este crate es necesario para el panic_handler</code> y también incluye varias funciones que utilizaremos mas adelante.</li> --target avr-atmega328p.json</code>: Le indica al compilador cual es el target custom que utilizaremos, en este caso es un json que ya está tuneado para el micro del Arduino.</li> --release</code>: Para que se tomen en cuenta los workarounds que agregamos al Cargo.toml</code> es necesario compilar en modo release.</li> </ol> Una acotación mas, y es que para poder compilar todo nuestro desmadrito, será necesario hacerlo en la versión nocturna del compilador, ya que utilizamos características como el build-std=core</code>, que no es posible utilizarlo en la rama estable.</p> >> cargo build -Z build-std=core --target avr-atmega328p.json --release Compiling compiler_builtins v0.1.85 Compiling core v0.0.0 (~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core) Compiling rustc-std-workspace-core v1.99.0 (~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core) Compiling arduino_blinkrs v0.1.0 (~/Proyectos/arduino_blinkrs) Finished release [optimized] target(s) in 16.59s </code></pre> La compilación se realizó con éxito :) oficialmente hemos programado un firmware para el Arduino con Rust. Pero aún faltan un montón de cosas, ya que de momento solo tenemos un firmware que no hace absolutamente nada. Lo siguiente que toca es aprender a manipular los registros que vimos anteriormente.</p> Hola hoja de especificaciones</h2> Pero antes tenemos que saber qué registros modificar y para ello no hay nada como consultar la propia hoja de especificaciones del ATmega328p</a>, pero como leer eso puede ser un poco abrumador, aquí la voy a resumir un poco: Los grupos de pines tienen asignada una letra que los identifica:</p> +-----+ +----[PWR]-------------------| USB |--+ | +-----+ | | GND/RST2 [ ][ ] | | MOSI2/SCK2 [ ][ ] A5/SCL[ ] | ══╗ | 5V/MISO2 [ ][ ] A4/SDA[ ] | ║ | AREF[ ] | ║ | GND[ ] | ║ | [ ]N/C SCK/13[ ] | Grupo | [ ]IOREF MISO/12[ ] | B | [ ]RST MOSI/11[ ]~| ║ | [ ]3V3 +---+ 10[ ]~| ║ | [ ]5v -| A |- 9[ ]~| ║ | [ ]GND -| R |- 8[ ] | ══╝ | [ ]GND -| D |- | | [ ]Vin -| U |- 7[ ] | ══╗ | -| I |- 6[ ]~| ║ ╔══ | [ ]A0 -| N |- 5[ ]~| ║ ║ | [ ]A1 -| O |- 4[ ] | Grupo Grupo | [ ]A2 +---+ INT1/3[ ]~| D C | [ ]A3 INT0/2[ ] | ║ ║ | [ ]A4/SDA RST SCK MISO TX►1[ ] | ║ ╚══ | [ ]A5/SCL [ ] [ ] [ ] RX◄0[ ] | ══╝ | [ ] [ ] [ ] | | UNO_R3 GND MOSI 5V ____________/ \_______________________/ </code></pre> Y como había dicho al inicio de la presentación, existen 3 registros para cada grupo de pines:</p> El registro para controlar en que modo van a estar los pines lo llamaremos "DDR", que significa "Data Direction Register".</li> El registro que contiene la información de salida, lo llamaremos "PORT", que significa... "PORT".</li> El registro que contiene la información de entrada, y su nombre es "PIN".</li> </ol> Y cada Pin tiene un bit asignado y se enumeran desde el 0 hasta el 7. Así que para construir una dirección a un Pin en concreto lo haremos de la siguiente manera: {Nombre del registro}{Letra identificativa}{número del bit}</p> Ejemplo</th> Descripción</th> </tr> </thead> PORTC5</td> 6to Pin del registro "PORT" grupo "C"</td> </tr> PINB</td> Todos los pines del registro "PIN" del grupo B</td> </tr> D2</td> 3er Pin del grupo "D" Sin determinar ningún registro en específico</td> </tr> DDRB6</td> 7mo Pin del registro "DDR" del grupo "B"</td> </tr> PINC9</td> No existe, recuerda que sólo hay 8 pines</td> </tr> </tbody> </table> Como dato relevante, el LED incrustado en la placa es el B5, solo para que lo sepan, ya que ese justamente será el que haremos parpadear.</p> Sabiendo eso, nos vamos a la tabla de especificamos, en el apartado en donde están los números de registros para saber cual es el DDR, PORT y PIN de la sección B.</p> Address</th> Name</th> Bit 7</th> Bit 6</th> Bit 5</th> . . .</th> </tr> </thead> . . .</td> </td> </td> </td> </td> </td> </tr> 0x06(0x26)</td> PINC</td> -</td> PINC6</td> PINC5</td> . . .</td> </tr> 0x05(0x25</strong>)</td> PORTB</strong></td> PORTB7</td> PORTB6</td> PORTB5</td> . . .</td> </tr> 0x04(0x24</strong>)</td> DDRB</strong></td> DDRB7</td> DDRB6</td> DDRB5</td> . . .</td> </tr> 0x03(0x23</strong>)</td> PINB</strong></td> PINB7</td> PINB6</td> PINB5</td> . . .</td> </tr> 0x02(0x22)</td> Reserved</td> -</td> -</td> -</td> -</td> </tr> . . .</td> </td> </td> </td> </td> </td> </tr> </tbody> </table> (Ver sección "Register summary" de la Hoja de especificaciones</a>) Solo vamos a tomar en cuenta el número que se encuentre entre paréntesis.</p> Y ¡bingo!, finalmente dimos con que la dirección de los registros Siendo 0x25 para el "PORTB", 0x24 para el "DDRB" y finalmente el 0x23 para el "PIN", recordando que están expresados en hexadecimal. Una vez teniendo esto, ya tenemos todo para ir a nuestro editor. Para interactuar con los registros vamos a necesitar un par de funciones que se encuentran dentro del crate core</code> y se llaman read_volatile</code> y write_volatile</code>. Y para mayor comodidad, pondremos en constantes las direcciones de los registros como punteros.</p> ... use core::ptr::{read_volatile, write_volatile}; const PORTB: *mut u8 = 0x25 as *mut u8; const DDRB: *mut u8 = 0x24 as *mut u8; const PINB: *mut u8 = 0x23 as *mut u8; #[no_mangle] pub extern "C" fn main() { unsafe { write_volatile(DDRB, 0b11111111) }; unsafe { write_volatile(PORTB, 0b00100000) }; } ... </code></pre> Con la primer linea de write_volatile</code> estamos colocando todo el grupo de pines de la sección "B" en modo OUTPUT (recuerden, 1 es OUTPUT y 0 es INPUT). Y con la segunda estamos colocando un valor de 1 (Voltaje alto) en PORTB5, que es justamente el que controla el Pin marcado como 13 en la placa, que a su vez es el que controla el LED naranja incluido en el Arduino. Con este código podemos apreciar 2 cosas:</p> write_volatile</code> (y read_volatile</code>) necesitan estar enjauladas en un bloque unsafe</code>, ya que modificarán directamente una dirección de memoria evadiendo por completo el verificador de seguridad de Rust.</li> write_volatile</code> recibe 2 parámetros, el registro que queremos modificar y el valor que vamos a asignar.</li> </ol> Compilamos para ver que todo esté funcionando correctamente y parece ser que si:</p> >> cargo build -Z build-std=core --target avr-atmega328p.json --release Compiling arduino_blinkrs v0.1.0 (~/Proyectos/arduino_blinkrs) warning: unused import: `read_volatile` --> src/main.rs:4:17 | 4 | use core::ptr::{read_volatile, write_volatile}; | ^^^^^^^^^^^^^ | = note: `#[warn(unused_imports)]` on by default warning: `arduino_blinkrs` (bin "arduino_blinkrs") generated 1 warning (run `cargo fix --bin "arduino_blinkrs"` to apply 1 suggestion) Finished release [optimized] target(s) in 0.20s </code></pre> Nuestro pequeño monstruo parece no tener ningún error (solo un pequeño warning, pero se sabe que esos se ignoran), así que en principio ya podríamos subir este resultado a la placa y ver que, efectivamente, el led de nuestra plaquita se prende, pero... como subimos el código al Arduino?.</p> Preparando el binario</h2> Lo primero es conectar por USB el Arduino a nuestra computadora, evidentemente. Despues, identificar cual puerto le asignó la PC a la placa. Esto lo podemos hacer entrando al Arduino IDE > Herramientas > Puerto y ver cual nos marca como "Arduino UNO". </p> En mi caso me asignó el /dev/ttyACM0. Ya identificado, podemos pasar a lo que sigue que es, la conversión del .elf a un .hex. Para hacer esa conversión vamos a necesitar una de las utilidades que instalamos al inicio llamada "avr-objcopy" y se utiliza de la siguiente manera:</p> avr-objcopy -O ihex -R .eeprom path/al/archivo.elf <output>.hex </code></pre> Que en este caso sería:</p> avr-objcopy -O ihex -R .eeprom target/avr-atmega328p/release/arduino_blinkrs.elf output.hex </code></pre> Siendo /target/avr-atmega328p/release/arduino_blinkrs.elf</code> nuestro binario de entrada y output.hex</code>, el archivo en donde volcará el resultado de la conversión. Lo ejecutamos y sí vemos que no arroja ningún error, eso es buena señal.</p> Lo siguiente ahora si es subirlo a nuestra placa, y para ello se hará uso de otra herramienta llamada avrdude</code>, y se utiliza de la siguiente manera:</p> avrdude -p atmega328p -c arduino -P <puerto del arduino> -U flash:w:</path/al/archivo.hex>:i </code></pre> que en este caso sería:</p> avrdude -p atmega328p -c arduino -P /dev/ttyACM0 -U flash:w:output.hex:i </code></pre> Lo ejecutamos y nos arroja un output parecido a este:</p> >> avrdude -p atmega328p -c arduino -P /dev/ttyACM0 -U flash:w:output.hex:i avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude: Device signature = 0xle950f (probably m328p) avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: reading input file "output.hex" avrdude: writing flash (178 bytes): Writing | ################################################## | 100% 0.04s avrdude: 178 bytes of flash written avrdude: verifying flash memory against output.hex: Reading | ################################################## | 100% 0.03s avrdude: 178 bytes of flash verified avrdude done. Thank you. </code></pre> El comando nos dice que todo el archivo output.hex</code> se volcó en el Arduino exitosamente. Y como podemos apreciar, el Led incorporado, se prende: </p> Y colocando un 0 en PORTB5:</p> pub extern "C" fn main() { unsafe { write_volatile(DDRB, 0b11111111) }; unsafe { write_volatile(PORTB, 0b00000000) }; } </code></pre> Volvemos, a compilar, convertir el .elf a un .hex y sublo al Arduibo, veremos como el led se apaga. </p> Pero yo les prometí al inicio un led parpadeante, no un led fijo, así que hay que hacer que parpadeé.</p> Como podrías intuirlo algunos, podemos simplemente meter el write_volatile</code> de PORTB</code> que hace prenda y se apague en un loop infinito y ya lo tendríamos, pero esto haría que se prenda y apague a una velocidad demasiada alta como para que fuera apreciable, así que tenemos que colocar un sleep de por medio.</p> std::thread\::sleep</code>?</h2> Por desgracia, el thread::sleep</code> solo se encuentra en la biblioteca estándar, y recordemos que estamos en un proyecto sin eso, así que tendremos que hacerlo de otra forma, como por ejemplo, hacer que el microcontrolador esté ejecutando operaciones vacías durante X ciclos y para hacerlo tendremos que adentrarnos a un nivel muy bajo. Muchos de los procesadores, incluyendo los AVR, tienen en su set de instrucciones una que no hace nada, y normalmente se llama "nop" o "no operation". Esto lo podemos consultar de nueva en la hoja de especificaciones del microcontrolador, en el apartado de "Instruction Set Summary"</a>.</p> Mnemonics</th> Operands</th> Description</th> Operation</th> Flags</th> #Clocks</th> </tr> </thead> . . .</td> </td> </td> </td> </td> </td> </tr> MCU CONTROL INSTRUCTIONS</td> </td> </td> </td> </td> </td> </tr> NOP</td> </td> No Operation</td> </td> None</td> 1</td> </tr> SLEEP</td> </td> Sleep</td> (see specific descr. for Sleep function)</td> None</td> 1</td> </tr> . . .</td> </td> </td> </td> </td> </td> </tr> </tbody> </table> Como se puede apreciar, efectivamente, el procesador AVR tiene una instrucción llamada "nop", que no hace nada, no recibe operadores y que gasta un único ciclo del procesador. También hay otra llamada "sleep" que hace lo mismo, pero "nop" puede ser mas extrapolable a otras arquitecturas, así que es el que utilizaremos aquí. Así que solo tendremos que hacer una llamada con ensamblador a esa instrucción tantas veces como necesitemos y listo, nuestra simulación de thread::sleep</code> quedaría lista. Ahora, el procesador del Arduino UNO va a 16 MHz o 16'000'000 Hz, eso significa que realiza 16 millones de instrucciones por segundo, así que sí queremos dormir al procesador durante un segundo, hay que ejecutar el "nop" 16'000'000 de veces, ya que, como vimos en la tabla anterior, solo gasta un ciclo. En Rust puedes hacer llamadas a ensamblador de manera cruda utilizando el macro asm!</code> que se encuentra dentro de core::arch</code> y recibe como parámetro el nombre de la instrucción. Para que sea mas sencillo de utilizar, haremos una función que reciba como parámetro el número de segundo que queramos que se "duerma" nuestro CPU y también pondremos en una constante la velocidad del CPU expresado en Hz, que en este caso es 16_000_000.</p> #![feature(asm_experimental_arch)] use core::arch::asm; const CPU_SPEED: u32 = 16_000_000; fn sleep(time: u32) { for _ in 0..(CPU_SPEED / 10 * time) { unsafe { asm!("nop") } } } </code></pre> Dejando de lado la feature asm_experimental_arch</code>, que es para habilitar el macro en las arquitectura donde aún es experimental, solo nos tocaría hacer un for que itere desde 0 hasta la velocidad del CPU multiplicado por el número de segundos y dentro del for llamar al "nop" y listo, el problema de la pausa está solucionado. Pero como pueden ver en el código, existe una división entre 10 en el número total de ciclos del procesador y es que realmente cada iteración del for se lleva mas de un ciclo. Esto ya es un poco mas bajo nivel, pero haré mi mejor esfuerzo para explicarlo y que se entienda. Si pegamos ese mismo código en godbolt</a>.</p> Rust</th> Ensamblador</th> </tr> </thead> use std::arch::asm; #[no_mangle] pub fn sleep(time: u32) { let cycles = 10_000_000 * time; for _ in 0..cycles { unsafe { asm!("nop") }; } }</pre></td> sleep: sub rsp, 40 . . . jne .LBB6_2 .LBB6_2: . . . .LBB6_3: mov</b> rax, . . . ═════════╗ lea</b> rdi, [rsp + 24] ║ call</b> rax ║ mov</b> dword ptr [rsp + 36], edx ║ mov</b> dword ptr [rsp + 32], eax ║ mov</b> eax, dword ptr [rsp + 32] ║ cmp</b> rax, 0 ║ jne</b> .LBB6_5 ║ add</b> rsp, 40 ║ ret ║ .LBB6_5: ║ nop</b> ║ jmp</b> .LBB6_3 ═════════╝</pre></td> </tr> </tbody> </table> Cada instrucción que ven a la derecha ("mov", "lea", "call", etc...) digamos que se lleva un ciclo del procesador (esto no es del todo cierto, ya que algunas instrucciones puede gastar varios ciclos, pero para que la explicación sea sencilla podemos decir que cada una de ellas es un ciclo gastado del procesador). Y efectivamente, en la sección LBB6_5</code> podemos ver como nuestro "nop" está ahí, gastando su respectivo ciclo, pero el iterador dentro del for se está llevamos como 10 mas o menos (todas las instrucciones de la sección LBB6_3</code> son las que hacen que el iterador funcione), así que cada ciclo realmente nos está costando ~10+1. Esa es la razón por la que todo lo dividimos entre 10, no es lo mas elegante pero tampoco estamos programando un reloj suizo, con llegar a un tiempo estimado creo que podemos quedar conformes en este experimento. Utilizar un while</code> con una variable mutable como contador utiliza mas o menos la misma cantidad de instrucciones, así que támbien utilizo el for</code> por que, a mi parecer, es mas sencillo de leer. Ahora si, mezclamos todo lo aprendido hemos aprendido y el resultado final es esta belleza:</p> #![feature(asm_experimental_arch)] #![no_std] #![no_main] use core::arch::asm; use core::ptr::{read_volatile, write_volatile}; const DDRB: *mut u8 = 0x24 as *mut u8; const PORTB: *mut u8 = 0x25 as *mut u8; const CPU_SPEED: u32 = 16_000_000; #[no_mangle] pub extern "C" fn main() -> ! { unsafe { write_volatile(DDRB, 0b11111111) }; loop { unsafe { write_volatile(PORTB, 0b00100000) }; sleep(1); unsafe { write_volatile(PORTB, 0b00000000) }; sleep(1); } } fn sleep(time: u32) { for _ in 0..(CPU_SPEED / 10 * time) { unsafe { asm!("nop") } } } #[panic_handler] fn panic(_info: &::core::panic::PanicInfo) -> ! { loop {} } </code></pre> Compilamos, convertimos y subimos y vemos como nuestro led, efectivamente, está parpadeando (mas o menos) cada segundo ✨\._.\ \._./ /._./</code>✨.</p> Mejorando un poco el código</h2> Peeeero, tener hardcodeado</a> el valor de PORTB en escritura puede que no sea lo mejor. Sí solo vamos a hacer que el led parpadeé pues no habría ningún problema, pero sí esto lo queremos extrapolar a una situación un poquito mas dinámica, creo que lo mejor sería leer el valor de PORTB, sea cual sea, y modificarlo para prender o apagar SOLO el bit que nos interesa. Para ello haremos uso de un par de operadores binario, resultando en este código:</p> ... loop { let mut portb_value = unsafe { read_volatile(PORTB) }; portb_value = portb_value ^ ( 1 << 5 ); unsafe { write_volatile(PORTB, portb_value) }; sleep(1); } ... </code></pre> Operador XOR (^)</h3> Comenzaré explicando el operador "^", támbien llamado "XOR". XOR es un operador booleano que compara 2 valores binarios y devuelve 1 sí solo uno de ellos es 1, de lo contrario, devuelve 0. Otra forma de verlo es que XOR es un "detector de diferencias", ya que devuelve 0 si los 2 valores que estás comparando son iguales y 1 si son diferentes. Creo que consultando su tabla de verdades es mas sencillo de ver:</p> Entrada A</th> Entrada B</th> Salida</th> </tr> </thead> 0</td> 0</td> 0</td> </tr> 0</td> 1</td> 1</td> </tr> 1</td> 0</td> 1</td> </tr> 1</td> 1</td> 0</td> </tr> </tbody> </table> Aquí se puede apreciar mejor lo que comentaba, tanto en el primero como en el ultimo caso, los valores son iguales, por que XOR regresa 0, pero en el 2do y en el 3ro son distintos, por lo cual va a regresar 1. Ahora, sí se aplica el operador XOR a un valor entero, la operación se haría una vez por cada bit del número. Pongamos de ejemplo 2 valores u8:</p> 7</th> 6</th> 5</th> 4</th> 3</th> 2</th> 1</th> 0</th> Valor</th> </tr> </thead> 1</td> 0</td> 1</td> 1</td> 1</td> 0</td> 0</td> 1</td> 185</td> </tr> </td> </td> </td> </td> </td> </td> </td> </td> ^</td> </tr> 1</td> 0</td> 0</td> 1</td> 1</td> 1</td> 0</td> 1</td> 157</td> </tr> </td> </td> </td> </td> </td> </td> </td> </td> =</td> </tr> 0</td> 0</td> 1</td> 0</td> 0</td> 1</td> 0</td> 0</td> 36</td> </tr> </tbody> </table> Gracias a esta cualidad, resulta muy útil el operador XOR para invertir un bit en específico de un número sin modificar alterar nada mas. Supongamos que tenemos el número (0b11110000 = 140) y queremos invertir su 6to bit, lo que podemos es aplicarle una operación XOR contra otro que tenga todos sus bits en 0, excepto el que queremos invertir (0b00100000 = 32). La primera vez que lo hagamos veremos como, efectivamente, el bit se invierte:</p> 0b11110000 ^ 0b00100000 = 0b11010000 = 208 </code></pre> Lo interesante, viene ahora. Ya que, al volver a hacer la misma operación XOR, pero ahora aplicandoselo al resultado que nos arrojó veremos como el bit vuelve a ser 1:</p> 0b11010000 ^ 0b00100000 = 0b11110000 = 240 </code></pre> Operadores de desplazamiento (<< y >>)</h3> Ahora que ya sabemos invertir un bit en un valor numérico, no les parece como muy de hueva estar escribiendo 0b00100000 en cada operación que hagamos? Pues no se preocupen, ya que existe otro operador binario que nos puede hacer la vida un poquito mas sencilla, funciona de la siguiente manera: Le damos un número X y una cantidad de 0's que queramos que se agreguen a ese X a la izquierda y por arte de magia, lo recorre. Con un ejemplo creo que se entiende mejor. Supongamos que tenemos el valor 0b101 y queremos desplazarlo 4 bits a la izquierda para que convierta en 0b101</strong>0000, pues simplemente tendríamos que escribir:</p> 0b101 << 4 = 0b1010000 = 80 </code></pre> Sí queremos que se desplace a la derecha es igual unicamente intercambiando el operador <<</code> por >></code>, y en lugar de agregar 0's, va descartando bits:</p> 0b1011111 >> 3 = 0b1011 = 11 </code></pre> Viendo de vuelta el código ahora si podemos ver que ocurre:</p> ... loop { let mut portb_value = unsafe { read_volatile(PORTB) }; portb_value = portb_value ^ ( 1 << 5 ); unsafe { write_volatile(PORTB, portb_value) }; sleep(1); } ... </code></pre> Cuando comienza el programa PORTB está en 0's, así que leemos el valor utilizando la función read_volatile</code>, a ese número le aplicamos una operación XOR para prender unicamente el bit 5 y lo escribimos de nuevo en el registro haciendo uso de write_volatile</code> y dormimos 1 segundo. En el siguiente ciclo, ya con PORTB5 encendido hacemos lo mismo, volvemos a leer su valor, aplicamos de vuelta XOR para ahora apagar el bit 5, escribimos dicho valor en PORTB y volvemos a dormir por un segundo y así hasta el infinito.</p> YYYYY LISTO!!!, logramos hacer que un led parpadeara escribiendo y leyendo código ensamblador, midiendo tiempos en el CPU, modificando registros, etc... pues saben que, nada de eso es útil. Y es que el ecosistema para sistema embebidos en Rust nos permite hacer todo esto de una manera mas sofisticada. No me malentiendan, lo que aprendimos aquí es bastante útil, sobretodo para entender como funcionan las tripas de nuestro querido Arduino, pero programar para embebidos en Rust no suele ser así. Imagina que quieres hacer una biblioteca para, por ejemplo, controlar un display de 7 segmentos. Puedes programarla de la forma que acabamos de ver, pero esto es poco portable para otras placas o arquitecturas, ya que no todas tienen los registros en los mismo lugares o no todos tienen un CPU con la misma velocidad, así que nuestra pobre biblioteca solo serviría para las Arduino UNO. Pero que pasa si les digo que la comunidad de Rust hace uso de una técnica para que todas las bibliotecas sirvan para todas las placas que existen y las que están por existir, practicamente sin que la persona que mantenga la biblioteca haga ningún cambio. Estimado público, dejenme presentarle a las ✨HAL✨.</p> Presentando a las HAL</h2> Las HAL (por sus siglas en inglés: Capa de abstracción del Hardware) es una técnica para hacer bibliotecas de manera genérica y completamente portables a otras plataformas. Funciona así: Existe un crate llamado embedded_hal</code>🤖, que contiene muchísimos Traits para todo lo que una placa suele tener (Pines digitales, analogícos, SPI's, UART's, I2C, etc...), pero no contiene ninguna implementación de ellos, solo son Traits que indican un estándar de como deben funcionar, por ejemplo: Los pines digitales deben tener un método llamado set_high</code> que seteé ese pin en voltaje alto, y otro llamado set_low</code> para lo contrario. el cómo se implemente eso en cada placa a ese crate no le importa, solo marca un éstandar. La ventaja de tener eso es que tu, como mantenedor de una biblioteca, puedes hacer tus funciones utilizando los métodos genéricos de embedded_hal</code>.</p> Si estás escribiendo una biblioteca📜 para controlar un display de 7 segmentos, necesitas 7 Pines digitales, uno para cada led individual. Entonces puedes crear un Struct que reciba esos Pines que implementen el Trait OutputPin</code> de embedded_hal</code> y utilizar los métodos set_low</code>, set_high</code> o toggle</code> dependiendo de que valor quieres que tome, todo eso sin saber siquiera en que arquitectura o placa va a ejecutarse, tu solo recibes Pines y los pones en high o low según lo requiera tu biblioteca.</p> Otra de las partes es el arduino_hal</code>⚡, la implementación como tal de los Traits de embedded_hal</code> para el Arduino UNO, ahí si es donde se podría aplicar lo aprendido en aquí. Así, la persona que implemente el arduino_hal</code> es la encargada de que cuando se mande llamar al método set_high</code> o set_low</code> del Pin, este realice las asignaciones en los registros PORTXY y DDRXY para prender o apagar ese Pin.</p> Así por último están las persona que mezclará todo para hacer su firmware💻, solo tiene que importar la biblioteca que quiera utilizar junto con el HAL específico para su placa y comenzar a utilizarla de una forma mucho mas sencilla.</p> La interacción entre las distintas partes se vería algo así:</p> embedded_hal <═════════════ Biblioteca 🤖 📜 ^ ^ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ arduino_hal <══════════════ Firmware ⚡ 💻 </pre> Una vez explicado esto, el mísmo código para hacer que el led parpadeante quedaría algo así utilizando un HAL llamado avr-hal</code>:</p> #![no_std] #![no_main] use arduino_hal::delay_ms; use panic_halt as _; #[arduino_hal::entry] fn main() -> ! { let peripherals = arduino_hal::Peripherals::take().unwrap(); let pins = arduino_hal::pins!(peripherals); let mut led = pins.d13.into_output(); led.set_high(); loop { led.toggle(); delay_ms(1000); } } </code></pre> Así ya se ve mucho mas sencillo, no? solo importamos el Pin asociado al led que queremos modificar, en este caso el B5 (este HAL no nombra los pines siguiendo la nomenclatura de la hoja de especificaciones, en su lugar hace uso de la nomenclatura impresa en la PCB, que para el led embebido sería el digital 13 o d13), támbien el HAL ya tiene funciones para hacer los delays, así que solo seteamos el pin como output y en el loop colocamos un toggle</code> y un delay y listo :), sin ensamblador, sin saber de registros, sin nosotros utilizar unsafe</code>, desde luego un API mucho mas amigable.</p> FIN</h2> Al final todo el código de este escrito lo puedes encontra en mi GitLab</a>, en el cual habrá 2 ramas, una llamada "low_level" que contiene el ejemplo manipulando los registros directamente y otra llamada "using_hal" con el ejemplo utilizando la HAL. Támbien pueden encontrar revisar la información de este mismo texto pero en formato charla en el canal de YouTube Software Guru</a></p> Espero les haya gustado y hayan aprendido lo básico de como es que funciona un microcontrolador a un nivel un poco mas bajo y como implementar ese conocimiento en Rust :), hasta la próxima.</p> Fuentes y enlaces de interés</h3> Hermoso asciiart del Arduino Uno http://busyducks.com/wp_4_1/2015/11/16/ascii-art-arduino-pinouts/</a></li> http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061A.pdf</a></li> https://doc.rust-lang.org/reference/items/external-blocks.html</a></li> https://os.phil-opp.com/freestanding-rust-binary/#panic-implementation</a></li> https://os.phil-opp.com/freestanding-rust-binary/#the-eh-personality-language-item</a></li> https://docs.rust-embedded.org/book/start/panicking.html</a></li> https://docs.rust-embedded.org/embedonomicon/custom-target.html</a></li> https://github.com/avr-rust/ruduino</a></li> https://arduino.stackexchange.com/questions/62488/elf-and-hex-equivalency-code-eeprom-fuses-and-lock-bits-all-in-one</a></li> </ul> Crear función que retorne un array con N valores por defecto en Rust - Const Generics Wed, 26 May 2021 02:28:43 GMT Hace unos días una persona en un grupo de Telegram preguntó el porqué solo se podían hacer arrays con valores por defecto de máximo 32 de longitud y la respuesta a ese predicamento realmente es un tanto absurda pero desde luego es muy interesante y radica en que... *redoble de tambores* ... las funciones para generar los arrays se debían escribir a mano, y de manera arbitraria decidieron que iban a escribir funciones para generar arrays de hasta 32 elementos. Ósea que tienen escritas las funciones mas o menos así [1</a>]:</p> impl<T> Default for [T; 0] where T: Default { ^ ╚═══════ Array de longitud 0 fn default() -> Self { [] ^ ╚═══════ Retorna un array vacío } } impl<T> Default for [T; 1] where T: Default { ^ ╚═══════ Array de longitud 1 fn default() -> Self { [T::default()] ^ ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═╩═════ Retorna un array con un elemento } } ... impl<T> Default for [T; 32] where T: Default { ^ ╚═══════ Array de longitud 32 fn default() -> Self { [T::default(), T::default(), T::default(), T::default(), ...] ^ ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═╩═════ Retorna un array con 32 elementos ESCRITOS A MANO } } </code></pre> y solo había de dos sopas, o ponían a una persona becada a implementar manualmente el resto de casos desde 33 hasta el máximo de usize</code> o encontraban una forma de resolverlo de una manera inteligente, y el equipo de Rust se puso a hacer lo 2do y agregaron en esta nueva release una cosa maravillosa llamada const generics</code>. Los const generics</code>, como su nombre lo deja entrever, es la posibilidad de utilizar valores constantes como datos genéricos dentro de una función y poder colocar esos constantes genéricos en el lugar en el que debe ir un valor constante. Explicado de esta manera puede quedar mas o menos confuso, pero veamos un ejemplo sin const generics</code> y uno con para ver la enorme maravilla que esto supone.</p> Entendiendo los Const Generics</h2> El ejemplo será el siguiente: Se tiene que hacer una función que retorne un array vacío de tipos unidad (suena feo en español "unit type", ya me disculparán), la longitud de ese array puede ser cualquier valor de 0 hasta el máximo de usize</code>.</p> Sin Const Generics</h3> trait Foo { fn zeros() -> Self; } impl Foo for [(); 0] { fn zeros() -> Self { [] } } impl Foo for [(); 1] { fn zeros() -> Self { [()] } } ... // Aquí irían las implementaciones para cada longitud de array impl Foo for [(); usize::MAX] { fn zeros() -> Self { [(); usize::MAX] } } </code></pre> playground</code></a> Como se puede apreciar, se debe crear un trait que contenga la función que nos interesa que haga la acción y que retorne un Self</code> y después implementar cada caso a mano y después poderla mandarla a llamar así:</p> let x: [(); 10] = Foo::zeros(); println!("{:?}", x); // [(), (), (), (), (), (), (), (), (), ()] </code></pre> Como pueden intuir este método deja muchas cosas que desear, principalmente lo de estar implementando a mano cada uno de los casos para los arrays... ahora les mostraré lo sencillo que es implementarlo gracias a los Const Generics.</p> Con Const Generics</h3> fn zeros<const N: usize>() -> [(); N] { ^ ^ ^ ^ ^ ^ ^ ^ ║ ║ ║ ║ ║ ║ ║ ╚═ Se puede colocar el const generic en el lugar de la longitud ║ ║ ║ ║ ║ ║ ║ (ahí solo pueden ir valores constantes). ║ ║ ║ ║ ╚═╩═╩═ El tipo del const generic. ║ ║ ║ ╚═ Nombre del const generic. ╚═╩═╩═ Palabra reservada para indicar que será un valor const generic. [(); N] ^ ╚═ Se crea el array de valores unidad y se coloca el const generic en el tamaño del array. } </code></pre> playground</code></a> Como se ve, el ejemplo con const generic queda mucho mas limpio, se ve de manera clara lo que hace y no se necesita un trait que contenta a la función, puede estar suelta y ser independiente. Y para utilizarla es idéntico a la versión anterior:</p> let x: [(); 10] = zeros(); println!("{:?}", x); // [(), (), (), (), (), (), (), (), (), ()] </code></pre> Generando arrays con valores por defecto</h2> Tomando en cuenta lo aprendido anteriormente podríamos pensar que generar un array con valores por defecto puede ser tan simple como recibir un genérico que tenga implementado el trait Default</code> y después generar el array tomando su valor por defecto y listo, pero veamos que no es tan sencillo:</p> fn fill_default<T: Default, const N: usize>() -> [T; N] { [T::default(); N] } </code></pre> playground (no compila)</code></a> Ya que si es implementado así y lo si intentamos compilar nos saldrá un error parecido a este:</p> error[E0277]: the trait bound `T: Copy` is not satisfied --> src/main.rs:2:5 | 2 | [T::default(); N] | ^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `T` | = note: the `Copy` trait is required because the repeated element will be copied help: consider further restricting this bound | 1 | fn fill_default<T: Default + std::marker::Copy, const N: usize>() -> [T; N] { | ^^^^^^^^^^^^^^^^^^^ </code></pre> Debido a que la manera de generar arrays con la sintaxis [Valor; longitud]</code> necesita que el valor implemente el trait Copy</code>, para que se genere todo de golpe, y el reto que se propone en esta publicación es necesitar unicamente que T implemente a Default y nada más, así que tendremos que encontrar otra forma de realizarlo. Luego de darle muchas vueltas decidí atacar el problema de la siguiente manera:</p> Hacer un iterador para que cada valor se vaya generando uno a uno y no sea necesario el trait Copy</code>.</li> Generar un Vec<T></code> gracias a ese iterador para después:</li> Utilizando el trait TryInto</code> convertir el Vec<T></code> a un array.</li> </ol> Y el resultado fue el siguiente:</p> use std::convert::TryInto; ^ ^ ^ ^ ╚═╩═╩═╩═ Nos traemos el trait TryInto fn fill_default<T: Default, const N: usize>() -> [T; N] { std::iter::repeat_with(|| T::default()) .take(N) <═╦═ iter .collect::<Vec<T>>() <═╬═ Vec<T> .try_into() <═╬═ Result<[T; N], _> .map_err(|_| ()) <═╬═ Result<[T; N], ()> .unwrap() <═╩═ [T; N] } </code></pre> Playground</code></a> Y ¡¡listo!! despues de pasear un poco los datos (que sí iter, luego Vec, luego Result, etc...) ya tenemos nuestra función que genera un array de tamaño N con valores por defecto sin depender de otro trait como Copy o Debug.</p> Curiosidades encontradas</h2> Aunque el problema ya está resuelto no quiero dejar pasar un par de curiosidades con respecto a este problema ya que, como pueden ver en el pedazo de código anterior nos encontramos con una linea particularmente curiosa... y sí, me refiero a esta:</p> .map_err(|_| ()) </code></pre> Ya que en un principio podría parecer que no es necesaria por que solo está generando un Result de otro Result, pero si nos deshacemos de ella nos encontraremos con este curioso error:</p> error[E0277]: `T` doesn't implement `Debug` --> src/main.rs:8:10 | 8 | .unwrap() | ^^^^^^ `T` cannot be formatted using `{:?}` because it doesn't implement `Debug` | = note: required because of the requirements on the impl of `Debug` for `Vec<T>` help: consider further restricting this bound | 3 | fn fill_default<T: Default + std::fmt::Debug, const N: usize>() -> [T; N] { | ^^^^^^^^^^^^^^^^^ </code></pre> Así es, el compilar nos está pidiendo que T implemente también el trait Debug</code> lo cual es bastante peculiar (o me lo pareció en un principio) pero después de analizarlo me hizo todo el sentido del mundo ya que, si llegase a fallar la conversión de Vec<T></code> a [T; N]</code> el compilador deberá saber como mostrar a T y eso se logra con el trait Debug</code>. Por lo tanto, la linea .map_err(|_| ())</code> nos está ayudando a disfrazar el error reemplazandolo por una unidad</a> (que si tiene implementado el trait Debug). Otra de las curiosidades es que, sí estás utlizando la versión noctura del compilador, podremos utilizar una función que aún no es estable del todo llamada "array map</a>" y con eso sí que reducimos bastante el código sin comprometer la legibilidad del mismo ya que bastará con generar un array del tamaño que queramos y al que después le mapearemos la función que le colocará los valores deseados, algo mas o menos así:</p> #![feature(array_map)] fn fill_default<T: Default, const N: usize>() -> [T; N] { [0; N].map(|_| T::default()) } </code></pre> Playground (compila con la versión nocturna)</code></a> Y hace basicamente lo mismo que se trató en la parte principal de este texto pero de una manera directa y sin tanta parafernalia.</p> Esta publicación no sería posible sin la inestimable ayuda de Categulario</a>.</h4> Fuentes</h2> https://doc.rust-lang.org/std/default/trait.Default.html</a></li> https://github.com/rust-lang/rust/issues/75243</a></li> https://www.joshmcguigan.com/blog/array-initialization-rust/</a></li> https://stackoverflow.com/questions/67963788/why-tryinto-needs-copy-trait-in-t/67964077?noredirect=1#comment120159571_67964077</a></li> (manera utilizando unsafe</code> de hacerlo, es una forma fea y por eso no la mostré arriba) https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=48f7b644bb823912aa4a904e3189a0bb</a></li> </ol> Optimizando código en Python Sat, 25 Jan 2020 04:55:20 GMT No es una sorpresa para nadie que Python no es de los lenguajes más rápidos en cuanto a operaciones por segundo se refiere. Parte de la culpa es del lenguaje, ya que al ser interpretado no puede tener un rendimiento igual a un lenguaje compilado, PEEEEEEERO otra gran parte de la culpa es de las personas que programan en dicho lenguaje. Esta entrada no se tratará directamente de como optimizar el código en general (eso podría ser en otra ocasión), sino que se tratará de ciertas cuestiones a tener en cuenta al momento de estar programando exclusivamente</strong> en Python. Tampoco se tocará la concurrencia y como podemos mejorar el rendimiento de nuestro código con ella.</p> * Anotaciones antes de comenzar</h3> Para medir el tiempo se utilizará el siguiente decorador</a>:</p> from cProfile import Profile def explain_time(f): def wrapper(*args, **kwargs): profile = Profile() profile.enable() # Comenzar conteo de operaciones output = f(*args, **kwargs) # Ejecutar función profile.disable() # Terminar conteo de operaciones profile.print_stats() return output return wrapper </code></pre> No entraré a explicarlo a profundidad, solo diré que es una manera mucho más detallada de saber cuanto tiempo le tomó a una función ejecutarse fijándose en cuanto tarda cada operación individualmente.</p> El indexado es más rápido que el método get</code> en los diccionarios</h2> Hay 2 maneras de acceder a la información que contiene un diccionario, indexando el valor utilizando la sintaxis de corchetes []</code> y utilizando el método get</code>. Ambos ofrecen ventajas y desventajas. La ventaja de utilizar get</code> es que el código se vuelve "tolerante" a fallas ya que, si no se encuentra registrado un valor con la llave que le hemos pasado, este no arrojará una excepción, sino que simplemente nos devolverá un None</code> por defecto, u otro valor que le pasemos como segundo parámetros.</p> d = { "a": -1 } >>> d.get("a") -1 >>> d.get("b") ^ ^ ╚═╩═ Usando el método "get", si la llave no se encuentra en el diccionario Retornará simplemente un "None" ╔═╦══════════════════════════════════╩═╝ v v None >>> d["a"] -1 >>> d["b"] ^ ^ ╚═╩═ Usando un indexado tradicional, si la llave no se encuentra Arrojará una excepción ╔═╦═════════════════════╩═╩═╩═╩═╝ v v --------------------------------------------------------------------------- KeyError Traceback (most recent call last) <ipython-input-212-07abf0799e3f> in <module> ----> 1 d["b"] KeyError: 'b' </code></pre> Pero este post no se trata sobre código tolerante a fallas, sino que se trata de código rápido; Y en rapidez, el indexado tradicional le gana al método get</code>. Y es que, si pones un indexado a competir contra get</code>, estos son los resultados:</p> # Prueba utilizando el indexado tradicional @explain_time def test_index(): d = { "a": -1 } for _ in range(100000): d["a"] >>> test_index(): 2 function calls in 0.007 seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 1 0.007 0.007 0.007 0.007 <ipython-input-250-319a0e1f128d>:2(test_index) 1 0.000 0.000 0.000 0.000 {method 'disable' of '_lsprof.Profiler' objects} # Prueba utilizando el método "get" @explain_time def test_get(): d = { "a": -1 } for _ in range(100000): d.get("a") >>> test_get() 100002 function calls in 0.023 seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 1 0.012 0.012 0.023 0.023 <ipython-input-252-96210b127bf1>:1(test_get) 1 0.000 0.000 0.000 0.000 {method 'disable' of '_lsprof.Profiler' objects} 100000 0.011 0.000 0.011 0.000 {method 'get' of 'dict' objects} </code></pre> la diferencia es clara, ¿no?, el indexado tarda de 0.007 segundos haciendo 100000 búsquedas, a diferencia de get</code> que tarda 0.023 segundos en hacer la misma cantidad de búsquedas. Aunque la diferencia sea clara, soy una persona de ciencia y eso me obliga a repetir la tarea varias veces para ver si el tiempo promedio nos sorprende. Y los resultados para sorpresa de nadie son los siguientes:</p> N°</th> index</th> get</th> </tr> </thead> 1</td> 0.008</td> 0.027</td> </tr> 2</td> 0.007</td> 0.027</td> </tr> 3</td> 0.006</td> 0.024</td> </tr> 4</td> 0.004</td> 0.023</td> </tr> 5</td> 0.011</td> 0.028</td> </tr> 6</td> 0.009</td> 0.032</td> </tr> 7</td> 0.009</td> 0.028</td> </tr> 8</td> 0.007</td> 0.027</td> </tr> 9</td> 0.009</td> 0.028</td> </tr> 10</td> 0.008</td> 0.031</td> </tr> promedio</td> 0.007</td> 0.027</td> </tr> </tbody> </table> Los print</code> son el infierno del rendimiento</h2> Cada vez que nosotros interactuamos con un buffer, este consume cierto tiempo de CPU, incluyendo al buffer de estándar de salida (stdout</code> para los amigos). Osea, nuestros print</code> están haciendo lento nuestro código. Justo por eso es una mala práctica hacer debuging a punta de print</code>'s en lugar de herramientas dirigidas a ello, como logging</code>. En sí logging</code> no hará nuestro código más rápido, pero si que nos permite elegir hasta que grado de importancia hará o no la petición al buffer de salida. Para ver esto es bastante sencillo, aquí los resultados:</p> # Prueba utilizando un "print" dentro de un ciclo @explain_time def test_print(): for _ in range(10000): result = 10-5 print(f"{result}", end="") >>> test_print() 55555...555 10002 function calls in 0.022 seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 1 0.004 0.004 0.022 0.022 <ipython-input-293-35e61664f972>:1(test_print) 10000 0.017 0.000 0.017 0.000 {built-in method builtins.print} 1 0.000 0.000 0.000 0.000 {method 'disable' of '_lsprof.Profiler' objects} # Prueba de ciclo sin llamadas a "print" dentro @explain_time def test_no_print(): for _ in range(10000): result = 10-5 >>> test_no_print() 2 function calls in 0.000 seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 1 0.000 0.000 0.000 0.000 <ipython-input-295-e65a75e6f856>:1(test_no_print) 1 0.000 0.000 0.000 0.000 {method 'disable' of '_lsprof.Profiler' objects} </code></pre> Aquí la diferencia es tan clara que ni siquiera haré tabla comparativa. El mismo for</code> con la misma operación matemática, tarda 0.022 segundos mostrando el resultado y 0.000 no mostrando el resultado. Así que si están desarrollando el backend de una página web, quiten los prints</strong> de su código.</p> Concatenar strings de la manera incorrecta</h2> Unir 2 strings es una tarea que debemos hacer prácticamente en todos los programas que hagamos... pero, ¿lo estamos haciendo de la manera más óptima?. Existen múltiples formas para hacer esa labor, ya sea desde utilizando el operador +</code>, utlizar el método join</code> de un string, utilizando la manera de formatear un texto como en C con el verbo %s</code> o métodos de formateo más propias de Python como el método format</code> o los f-strings. Bien, cada una de esas técnicas consumen más o menos recursos. Como aquí iba a quedar muy largo todo el código que utilicé para medir los tiempos, dejo un enlace a un snippet</a> por si les interesa verlo. De igual forma, aquí les dejo los resultados ordenados de peor a mejor:</p> técnica</th> tiempo</th> </tr> </thead> método "format"</td> 0.066</td> </tr> método "join"</td> 0.049</td> </tr> verbos C-like</td> 0.037</td> </tr> operador +</td> 0.029</td> </tr> f-strings</td> 0.024</td> </tr> </tbody> </table> Como podemos apreciar, los f-strings</code> son la manera más rápida para concatenar 2 strings... pero tienen un pequeño defecto, y es que no podemos declarar f-strings "al vuelo" ya que su poder radica justo en el hecho de que el interprete ya sabe de antemano que justo ahí tendrá que hacer un concatenado de strings. Así que si queremos unir 2 strings sobre la marcha, nuestra segunda mejor opción es usar el operador +.</p> Cachear resultados de funciones</h2> Una de las bases que definen la programación funcional es "siempre que mandes llamar una función con los mismos parámetros, está te devolverá el mismo resultado", y en base a ella se creó el lru_cache</code> (least recently used). El concepto es muy simple de entender. Sí nosotros mandamos llamar por primera vez una función, esta tiene que calcular el resultado para posteriormente retornarlo, si el resultado de la segunda vez que la mandemos llamar el resultado también debe ser el mismo, entonces, ¿Para qué volver a calcular el resultado si ya esa tarea la hicimos anteriormente?. Creo que con un ejemplo se entiende mejor.</p> from time import sleep from functools import lru_cache ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═ Se importa el decorador del paquete "functools" ╔═╦═╦═╦═╦═╦═ Le indicamos que puede guardar hasta un máximo de 100 resultados v v v v v v @lru_cache(maxsize=100) def is_even(x): sleep(2) <═ Simulando una tarea muy tardada return x%2 == 0 @explain_time def test_100_numbers(): for n in range(1, 101): is_even(n) >>> test_100_numbers() 202 function calls in 200.195 seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 100 0.001 0.000 200.193 2.002 <ipython-input-334-f1ecb61062cb>:1(is_even) 1 0.002 0.002 200.195 200.195 <ipython-input-335-c237fa081463>:2(test_100_numbers) 100 200.192 2.002 200.192 2.002 {built-in method time.sleep} ^ ^ ╚═╩═ Hace 100 llamadas a la función "sleep" 1 0.000 0.000 0.000 0.000 {method 'disable' of '_lsprof.Profiler' objects} >>> test_100_numbers() 2 function calls in 0.000 seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 1 0.000 0.000 0.000 0.000 <ipython-input-335-c237fa081463>:2(test_100_numbers) 1 0.000 0.000 0.000 0.000 {method 'disable' of '_lsprof.Profiler' objects} ^ ^ ╚═╩═ Las llamadas a "sleep" desaparecen </code></pre> Como podemos apreciar, la primera vez que corremos el test que medirá si un número es par o no, a este le tomará 200 segundos (gracias al delay enorme que le pusimos a la función is_even</code>), pero la segunda vez que corremos el test esté es terminado de inmediato, esto gracias a que los resultados de la función quedaron cacheados en memoria y cuando se volvió a llamar la función, esta ya no se ejecutó como tal librándonos del delay. Aunque esto pueda ser realmente bueno, hay que tener cuidado y pensar muy bien cual función puede ser cacheada y cual no, pero si utilizamos el caché a conciencia, nos traerá muchas bondades a nuestro código.</p> Conclusiones</h2> Aunque Python no sea el lenguaje más rápido que pueda existir, su rendimiento en general no está nada mal y conociendo estos pequeños consejos, pueden escribir código con mejor rendimiento. Por otra parte, el rendimiento no lo es todo en un lenguaje y si sacrificamos un poco de rendimiento por tener un código más limpio o un código más tolerante a fallas, pues es un sacrificio que vale la pena.</p> Fuentes</h2> https://docs.python.org/3.8/library/functools.html</a></li> https://docs.python.org/3.8/library/profile.html</a></li> https://twitter.com/raymondh/status/1205969258800275456</a></li> https://martinheinz.dev/blog/13</a></li> </ol> Actualizaciones</h4> 28-02-2020</strong>: Arreglados algunos typos. Gracias VMS.</p> Poetry: un gran gestor de proyectos para Python Fri, 17 Jan 2020 04:26:46 GMT Dos de las cosas que peor están resueltas en Python es le definición de dependencias y el aislamiento de proyectos. Seamos sinceros, almacenar las dependencias de un proyecto en requierements.txt</code> de forma manual o con el comando:</p> $> pip freeze > requierements.txt </code></pre> es una manera bastante mala de llevar un continuo seguimiento de todas las dependencias, ya que es muy probable que no siempre ese archivo se mantenga actualizado, ya que se debe escribir de manera manual y separada del proyecto en si. Los entornos virtuales son otro tema que está resuelto a medias porque, de nuevo, se deben activar de manera manual y eso al final solo está agregando complejidad innecesaria para poder arrancar el proyecto. Maneras de resolver esto hay muchas y hoy les vengo a platicar de mi preferida, Poetry.</p> Poetry es una manera de tener correctamente controladas las dependencias del proyecto y poderlo aislar de una manera transparente para nosotros. Su manera de funcionar no dista demasiado de gestores de proyectos de otros lenguajes como npm, yarn, cargo o composer. En esencia, es un archivo que contiene toda la información y requerimientos que nuestro proyecto necesita para funcionar.</p> Instalación</h2> La instalación es bastante sencilla y como única dependencia, debemos ya tener instalado Python en nuestro equipo.</p> Si nuestro equipo tiene alguna distribución de GNU/Linux, MacOS o es windows con bashonwindows, basta con ejecutar el comando:</p> $> curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | python </code></pre> O si nada mas estamos en Windows y tenemos powershell, se instala con el siguiente comando (Todo este blog fue escrito enteramente en GNU/Linux y no fue probado en Windows):</p> $> (Invoke-WebRequest -Uri https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py -UseBasicParsing).Content | python </code></pre> Para verificar que se instaló correctamente se ejecuta el comando:</p> $> poetry --version Poetry 0.12.17 </code></pre> Mas información acerca de la instalación en la web oficial</a>.</p> Creación de un nuevo proyecto</h2> Ahora si, dejando la parte mas tediosa a un lado, comencemos ahora si con lo interesante. Para crear un nuevo proyecto de Poetry debes escribir el siguiente comando:</p> $> poetry new «nombre del proyecto» </code></pre> Lo cual creará los siguientes archivos y carpetas</p> example/ ├── example │ └── __init__.py ├── pyproject.toml ├── README.rst └── tests ├── __init__.py └── test_example.py </code></pre> y si queremos hacer compatible un proyecto ya existente con Poetry, solo debemos escribir:</p> $> poetry init </code></pre> Nos hará una serie de preguntas como, ¿Cuál es el nombre del proyecto?, ¿En qué versión va?, ¿Quién lo creó? entre otras cosas. Ya sea que lo hayamos creado con new</code> o con init</code>, en ambos casos nos creará un archivo pyproject.toml</code> el cual es el responsable de que la magia ocurra. Dicho archivo contiene la siguiente información:</p> # pyproject.toml [tool.poetry] name = "example" ^ ^ ^ ^ ╚═╩═╩═╩═ Nombre del proyecto version = "0.1.0" ^ ^ ^ ╚═╩═╩═ Versión actual del proyecto description = "Proyecto de prueba" ^ ^ ^ ^ ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═╩═╩═╩═╩═ Descripción del proyecto (útil si se quiere subir posteriormente a PyPI) authors = ["kirbylife"] ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═ La o las personas que mantienen el proyecto [tool.poetry.dependencies] python = "^3.6" ^ ^ ╚═╩═ Versión de Python que usará el proyecto ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═ En esta parte del documento irán las demás dependencias del proyecto [tool.poetry.dev-dependencies] pytest = "^3.0" ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═ Aquí irán las dependencias que solo serán necesarias para pruebas o depuración [build-system] requires = ["poetry>=0.12"] ^ ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═╩═ Versión de Poetry que se está utilizando build-backend = "poetry.masonry.api" ^ ^ ^ ^ ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═╩═╩═╩═╩═ Compositor del proyecto (solo tocar en caso de saber lo que estás haciendo) </code></pre> Como podemos ver, es un resumen bastante completo del proyecto en si, ya que incluye desde meta-información como el nombre, la descripción y las personas que los mantienen, hasta la dependencias que el proyecto necesita.</p> Manejo de dependencias</h2> Una de las cosas que mas me gusta de Poetry es su manejo de dependencias, y es que, tenerlas todas recopiladas y que no se puedan utilizar dentro del proyecto si no está listada es un gran alivio para evitar "sorpresas" cuando se quiera subir a producción. Para añadir una nueva dependencia es bastante sencillo y lo podemos hacer desde la linea de comando con la instrucción poetry add</code> como en este ejemplo:</p> $> poetry add requests Creating virtualenv example-py3.6 in /home/kirbylife/.cache/pypoetry/virtualenvs Using version ^2.22 for requests ... - Installing requests (2.22.0) </code></pre> Una vez completado todo el proceso de instalación podemos fijarnos que se agregó el paquete requests</code> al apartado de dependencias dentro de nuestro archivo pyproject.toml</code>.</p> # pyproject.toml ... [tool.poetry.dependencies] python = "^3.6" requests = "^2.22" ^ ^ ^ ^ ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═╩═╩═╩═╩═ Paquete "requests" añadido a la lista de dependencias con todo y su versión ... </code></pre> Otra forma de añadir dependencias es escribirla manualmente en el archivo pyproject.toml</code> y posteriormente actualizar el listado de dependencias. Aquí un ejemplo:</p> # pyproject.toml ... [tool.poetry.dependencies] python = "^3.6" requests = "^2.22" beautifulsoup4 = "4.8.2" ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═ Paquete "beautifulsoup4" escrito manualmente con todo y versión ... </code></pre> La versión del paquete se puede consultar directamente en la web de PyPI</a>. Y una vez modificado solo basta ejecutar la instrucción update</code> de Poetry para efectuar los cambios:</p> $> poetry update Updating dependencies ... - Installing beautifulsoup4 (4.8.2) </code></pre> Lo mismo aplica para las dependencias de pruebas y depuración. Basta con agregar la bandera --dev</code> o -D</code> al comando add</code> de Poetry para indicar que coloque esa dependencia en el apartado de "dev", o la podemos escribir manualmente en su correspondiente apartado y ejecutar la instrucción update</code>.</p> $> poetry add ipython --dev Using version ^7.11 for ipython ... - Installing ipython (7.11.1) </code></pre> Agregando así la dependencia a nuestro listado de paquetes para depuración.</p> # pyproject.toml ... [tool.poetry.dev-dependencies] pytest = "^3.0" ipython = "^7.11" ... </code></pre> ¡Y listo! dependencias añadidas de una manera controlada, simple ¿verdad?.</p> Escribiendo código</h2> Bien, ya sabemos como agregar dependencias, pero ahora... ¿Cómo y en donde escribimos nuestro código?. Pues bien, aunque el código realmente lo podemos escribir y añadir en la raíz del proyecto, lo mas adecuado sería crear una carpeta con el mismo nombre de nuestro proyecto dentro de la carpeta raíz con su correspondiente archivo __init__.py</code> y ahí colocar el código. Esto se hace de manera automática si el proyecto lo creamos de 0 con la herramienta de linea de comandos de Poetry, pero lo tendremos que hacer a mano si el proyecto lo creamos con la instrucción init</code>. Aquí un ejemplo de como quedaría un proyecto simple con esta estructura.</p> example/ ├── example │ ├── __init__.py │ └── main.py │ ^ ^ ^ ^ │ ╚═╩═╩═╩══ Creé un nuevo archivo llamado "main.py" ├── poetry.lock ├── pyproject.toml └── README.rst </code></pre> Y dentro del archivo main.py</code> está el siguiente código de ejemplo:</p> # example/main.py import re def is_prime(n): return not re.match(r"-?$|^(--+?)\1$", "-"*n) def primes(a, b): return list(filter(is_prime, range(a, b))) def main(): print("Calculo de números primos") a = int(input("Límite inferior: ")) b = int(input("Límite superior: ")) result = primes(a, b) print(f"Todos los números primos que hay entre {a} y {b} son:") print(", ".join(map(str, result))) if __name__ == "__main__": main() </code></pre> Como pueden ver, es un código sin nada demasiado destacable (no me maten por validar números primos con regex, es solo un código de ejemplo). De esta manera tan simple y realmente cotidiana, se puede mantener una estructura poco caótica de nuestro proyecto lo cual, a la larga, será muy beneficioso. Pero ahora, ¿Cómo se corre el código?.</p> Ejecución de comandos</h2> Bien, ya sabemos agregar dependencias y sabemos como debemos mantener la estructura de nuestro proyecto, pero ¿Cómo puedo ejecutar mi proyecto? Poetry incluye una instrucción llamada run</code> que nos permite ejecutar comandos que se encuentran encapsulados dentro del entorno virtual de nuestro proyecto. Así ejecutaríamos el código anteriormente escrito:</p> $> poetry run python example/main.py Calculo de números primos Límite inferior: 10 Límite superior: 50 Todos los números primos que hay entre 10 y 50 son: 11, 13, 15, 17, 19, 21, 23, 25, 27, 29, 31, 33, 35, 37, 39, 41, 43, 45, 47, 49 </code></pre> Como podemos apreciar, solo debemos escribir poetry run</code> + el comando de toda la vida que queramos ejecutar. Aparte de tener esta opción, Poetry nos ofrece una manera de añadir atajos a al instrucción run</code> para que sea mas sencillo ejecutar nuestro proyecto. Esto se hace añadiendo una nueva sección al archivo pyproject.toml</code> llamada "scripts". Aquí un ejemplo de las partes de un atajo:</p> # pyproject.toml ... [tool.poetry.dev-dependencies] pytest = "^3.0" ipython = "^7.11" [tool.poetry.scripts] start = "example.main:main" ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ║ ║ ║ ║ ║ ║ ║ ║ ║ ╚═╩═ Nombre de la función a ejecutar ║ ║ ║ ║ ║ ║ ║ ╚═╩═ Nombre del archivo que contiene la función ║ ║ ║ ╚═╩═╩═╩═ Nombre de la carpeta que contiene el archivo ╚═╩═╩═ Nombre del atajo [build-system] requires = ["poetry>=0.12"] build-backend = "poetry.masonry.api" </code></pre> Una vez añadida esa opción a nuestro archivo todopoderoso pyproject.toml</code>, solo bastará con ejecutar el comando:</p> >$ poetry run start ^ ^ ^ ╚═╩═╩═ Nombre del atajo Calculo de números primos Límite inferior: 10 Límite superior: 50 Todos los números primos que hay entre 10 y 50 son: 11, 13, 15, 17, 19, 21, 23, 25, 27, 29, 31, 33, 35, 37, 39, 41, 43, 45, 47, 49 </code></pre> Y listo, eso simplifica bastante las cosas, ¿no? ahora es mucho mas fácil recordar el comando para cumplir con la acción. En el ejemplo anterior ejecuté el código que había escrito, pero no solo sirve para eso, ¿Recuerdan que instalé ipython</code> como una dependencia de depuración? pues bien, para abrir el shell de ipython solo debemos escribir en la terminal:</p> $> poetry run ipython Python 3.6.9 (default, Dec 6 2019, 13:53:25) Type 'copyright', 'credits' or 'license' for more information IPython 7.11.1 -- An enhanced Interactive Python. Type '?' for help. In [1]: </code></pre> Esto funciona con todos los demás paquetes que agreguen un binario que puede ser accesible desde la terminal.</p> Pruebas unitarias</h2> Escribir pruebas unitarias es una parte que no podemos omitir NUNCA si queremos escribir código fiable y Poetry puede ser un buen aliado para llevar a cabo este objetivo. Para hacer esta tarea mucho mas sencilla, dentro del proyecto debe existir una carpeta llamada "test" y dentro de esa carpeta, todos los archivos en donde escribiremos nuestras pruebas unitarias. Si nuestro proyecto lo creamos desde 0 con Poetry, esto ya vendrá incluido, pero si lo iniciamos con la instrucción init</code> tocará hacer la carpeta y los archivos a mano. importante</strong>, los archivos de pruebas deben tener al inicio de su nombre "test_". Al final la estructura del proyecto queda así:</p> example/ ├── example │ ├── __init__.py │ └── main.py ├── poetry.lock ├── pyproject.toml ├── README.rst └── tests ├── __init__.py └── test_example.py ^ ^ ^ ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═╩═╩═╩═ Archivo que contendrá nuestras pruebas unitarias. </code></pre> Aquí dejo de ejemplo unas cuantas pruebas unitarias.</p> # tests/test_example.py from example import __version__ from example.main import is_prime, primes def test_version(): assert __version__ == '0.1.0' def test_2_is_prime(): assert is_prime(2) def test_4_is_not_prime(): assert not is_prime(4) def test_113_is_prime(): assert is_prime(113) def test__minus_1_is_not_prime(): assert not is_prime(-1) def test_range_from_10_to_30_of_prime_numbers(): numbers = primes(10, 30) assert numbers == [11, 13, 15, 17, 19, 21, 23, 25, 27, 29] </code></pre> Para correr los tests basta con llamar al ejecutable pytest</code> utilizando la instrucción "run":</p> $> poetry run pytest ============================= test session starts ============================= platform linux -- Python 3.6.9, pytest-3.10.1, py-1.8.1, pluggy-0.13.1 rootdir: /home/kirbylife/Temp/example, inifile: collected 6 items tests/test_example.py ...... [100%] ========================== 6 passed in 0.02 seconds =========================== </code></pre> Y si queremos mapear un atajo por si en un futuro agregamos mas tests con diferentes herramientas, debemos modificar un poco el archivo tests/__init__.py</code> para que quede así:</p> # tests/__init__.py from pytest import main as pytest_main def run_all_tests(): pytest_main() ^ ^ ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═╩═╩═ Aquí se podrán apilar los tests de todos los frameworks que necesitemos </code></pre> y el atajo en el archivo pyproject.toml</code> quedaría así:</p> # pyproject.toml ... [tool.poetry.scripts] start = "example.main:main" tests = "tests:run_all_tests" ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ║ ║ ║ ║ ║ ║ ╚═╩═╩═╩═╩═╩═╩═ Nombre de la función que dispara todas las pruebas ║ ║ ║ ╚═╩═╩═ Nombre de la carpeta donde se encuentras todas las pruebas ╚═╩═╩═ Nombre del atajo ... </code></pre> Y como mas o menos lo pueden intuir, las pruebas se correrán con el comando:</p> ❯ poetry run tests ^ ^ ^ ╚═╩═╩═ Nombre del atajo ============================= test session starts ============================= platform linux -- Python 3.6.9, pytest-3.10.1, py-1.8.1, pluggy-0.13.1 rootdir: /home/kirbylife/Temp/example, inifile: collected 6 items tests/test_example.py ...... [100%] ========================== 6 passed in 0.02 seconds =========================== </code></pre> Crear paquete wheels</h2> Poetry no solo nos permite mantener en control todo lo relacionado con nuestros proyectos, sino que también nos hace la vida mas sencilla en caso de que queramos distribuirlos ya que nos permite construir todo nuestro proyecto en un paquete de wheels. Hacerlo es súper sencillo, solo ejecutamos la instrucción build</code>:</p> $> poetry build Building example (0.1.0) - Building sdist - Built example-0.1.0.tar.gz - Building wheel - Built example-0.1.0-py3-none-any.whl </code></pre> Eso creará una carpeta llamada "dist" y dentro nuestro paquete wheels. Estos paquetes, por si no lo sabes, es la manera en la que Python por defecto maneja los paquetes. Si queremos que otra persona utilice nuestro hermoso código, no es necesario que tenga Poetry instalado, solo le compartimos el archivo .whl</code> y lo puede instalar en su equipo utilizando pip</code> de toda la vida:</p> $> pip install example-0.1.0-py3-none-any.whl --user Processing ./example-0.1.0-py3-none-any.whl ... Successfully installed beautifulsoup4-4.8.2 example-0.1.0 requests-2.22.0 </code></pre> Y ahora será capaz de utilizar nuestro código en su propio shell. Aquí una demo:</p> In [1]: from example import main In [2]: main.main() Calculo de números primos Límite inferior: 10 Límite superior: 30 Todos los números primos que hay entre 10 y 30 son: 11, 13, 15, 17, 19, 21, 23, 25, 27, 29 In [3]: main.is_prime(100) Out[3]: False In [4]: main.is_prime(113) Out[4]: True </code></pre> Conclusiones</h2> Bueno, a grandes rasgos eso es Poetry. ¿Qué les pareció? ¿Lo usarían en sus proyectos personales o profesionales? Personalmente soy un gran fan de este gestor de proyectos y considero que es indispensable una herramienta como estas, tanto en proyecto pequeñitos como en los proyectos mas gigantescos. Si no te terminó de convencer Poetry, tambien puedes investigar acerca de otras herramientas que cumplen funciones parecidas como pipenv</a> o virtualenvwrapper</a> pero lo importante es que usen alguno. Subí el proyecto que utilice para realizar este post a mi gitlab</a>, por si quedaron dudas sobre la estructura o el código en general.</p> Sección extra: Posibles problemas</h2> Error [TooManyRedirects] al intentar añadir un nuevo paquete</h3> Para solucionarlo es muy sencillo, basta con limpiar el caché de Poetry así:</p> $> poetry cache:clear --all pypi Delete 332 entries? (yes/no) [no] yes </code></pre> Fuentes</h2> https://python-poetry.org/docs/</a></li> https://github.com/python-poetry/poetry/issues/728</a></li> https://docs.pytest.org/en/latest/usage.html</a></li> </ol> ¿Por qué Python3 es objetivamente mejor que Python2? Fri, 27 Dec 2019 08:41:20 GMT Ya está casi por concluir el año 2019 y con el se va uno de los monstruos de software que nos dio esta década, Python2. Python2 nos ha acompañado a la largo de todo este tiempo como uno de los lenguajes mas simples pero poderosos y para homenajear todo su legado, en este post listaré todas las cosas por las cuales se estaba quedando obsoleto y porque la Python Software Foundation</em> tomó la excelente decisión de dejarlo morir, ahí, solo, desangrándose y pidiendo clemencia. Este será un repaso de las caracteristicas que hacen a Python3 OBJETIVAMENTE</strong> mejor que su antecesor al cual ya no le quedaba superficie para colocar parches.</p> Optimización de memoria y CPU con iteradores</h2> ¿Cuántos range</code> o map</code> no hemos escrito a lo largo de nuestro tiempo desarrollando en Python? pues si bien, estos métodos son muy bonitos y prácticos, también representaban un gran desperdicio de memoria ya que se ejecutaba todo el código de golpe ocupando demasiado espacio.</p> # Python2 >>> range(100) [0, 1, 2, 3, 4, 5, ..., 97, 98, 99] >>> type(range(100)) ^ ^ ^ ╚═╩═╩═ La función "range" retorna una lista ╔═╦════════════════════════════════════════════╩═╩═╝ v v list # Python3 >>> range(100) range(0, 100) >>> type(range(100)) ^ ^ ^ ╚═╩═╩═ La función "range" retorna un objeto de tipo "range" ╔═╦═╦═════════════════════════════════════════════════════════╩═╩═╝ v v v range </code></pre> La cosa está bastante clara, no? en Python2 cuando nosotros declarábamos un range</code>, en memoria se guardaban todos los números de de inicio a fin en una lista. ¿Son necesarios todos los números de golpe? probablemente no, pero aún así Python2 los generaba todos al mismo tiempo. Otra forma de ver esto es con la función map</code>.</p> import sys # Python2 >>> map(sys.exit, [0, 1, 2]) ^ ^ ╚═╩═ La función "map" ejecuta la función "sys.exit" al momento de ser ejecutado y sale del shell ╔═══════════════════════════════════════════════╩═╩═╝ v $> echo $? 0 # Python3 >>> map(sys.exit, [0, 1, 2]) >>> next(map(sys.exit, [0, 1, 2])) ^ ^ ^ ^ ╚═╩═╩═╩═ La función "map" ejecuta la función "sys.exit" solo al pedir un ítem, y hasta entonces, sale del shell ╔══════════════════════════════════════════════════════════════╩═╩═╝ v $> echo $? 0 </code></pre> Aquí con map las cosas son claras, en Python2 la función se mapeaba para TOOOODOS</strong> los elementos de la lista al momento de declarar el map</code>. A diferencia de Python3, en donde la función es mapeada a cada elemento solo al momento de pedir el siguiente valor, pudiendo evitar así utilizar tiempo de CPU en vano. La gran desventaja de range</code> fue parcheada con otra función llamada xrange</code> que hacía algo similar a la función range</code> de Python3. También lo corrigieron usuarios con implementaciones propias de range</code>, en este snippet</a> pueden ver la que yo creé en su momento. Aunque las funciones mencionadas en este apartado solo fueron range</code> y map</code>, esta optimización la recibieron también los zip</code>, filter</code> y los métodos keys</code>, values</code> e items</code> de los diccionarios.</p> La división retorna enteros</h2> No se si ustedes han tenido ese presentimiento de "creo que no estoy casteando</em> lo suficiente mis variables", pues justo ese sentimiento era el que presentaba al momento de intentar hacer una división en Python2 ya que si ambas variables eran int</code>, el resultado sería otro int</code> aunque la división tuviera residuo, y para evitar eso, se tenía que castear</em> (perdónenme pero no encontré una traducción al español para "cast") uno de los datos a float</code> si queriamos el resultado completo, aunque fuera un 10 / 3</code>.</p> num1 = 15 # Python2 >>> 10 / 3 ^ ╚═ El operador de división nos devuelve unicamente la parte entera ╔═══════════════════════════════════════════════════════════════════╩═╩═╝ v 3 >>> 10. / 3 ^ ╚═ Si la división involucra por lo menos a un número "float", el resultado será el valor exacto con precisión en decimales ╔═══════════════════════════════════════════════════════════╩═╩═╩═╩═╝ v 3.3333333333333335 ^ ╚═ (¿Este 5?, pronto explicaré la precisión con decimales) >>> num1 / 4 3 >>> float(num1) / 4 ^ ^ ^ ╚═╩═╩═ Era necesario castear la variable a float si queríamos el valor completo ╔═══════════════════════════════════════════════════════════════════════════╩═╩═╩═╝ v 3.75 # Python3 >>> 10 / 3 ^ ╚═ Operador de división normal retorna el valor el valor preciso ╔═══════════════════════════════════════════════════════════════╩═╩═╩═╝ v 3.3333333333333335 >>> num1 / 4 3.75 >>> num1 // 4 ^ ╚═ Nuevo operador de división que retorna unicamente la parte entera ╔═══════════════════════════════════════════════════════════════════════╩═╩═╝ v 3 >>> num1 // 4.0 ^ ╚═ Si con el nuevo operador uno de los 2 valores es "float", el resultado será unicamente la parte entera pero en un float ╔══════════════════════════════════════════════════════════════════════╩═╩═╝ v 3.0 </code></pre> Pero es probable que en ocasiones nos interese unicamente la parte entera de la división en Python3 y los casteos</em> del infierno volverían a aparecer (int(10 / 4)</code>), así que la gente de Python, muy inteligentemente, implementaron un nuevo operador, el //</code>. Este nuevo operador tiene un comportamiento parecido a la división de Python2, si la división es entre enteros, el resultado será un int</code>, y si nuestra división involucra por lo menos float</code>, el valor resultante será unicamente la parte entera de la división pero mostrada en un float</code>. A pesar de esta implementación, muchos seguiremos casteando</em> nuestras variables "por si las dudas".</p> Scope diferente para las listas de compresiones</h2> Este es muy sencillo de explicar pero cuantos quebraderos de cabeza no nos llegó a dar en su momento y es que antes las variables utilizadas en las listas de compresiones estaban con un scope al mismo nivel que nuestro bloque actual, con el ejemplo se verá mas claramente.</p> count = -10 ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═ Variable "count" declarada en el bloque actual con un valor de -10 items = [count**2 for count in range(1, 10)] ^ ^ ^ ^ ^ ^ ╚═╩═╩════════╩═╩═╩═ Variable "count" también es utilizada en una lista de compresión # Python2 >>> count ^ ^ ^ ╚═╩═╩═ Al consultar el valor de "count", este cambió al ultimo valor del for ╔════════════════════════════════════════════════════════════════════════════╩═╝ v 4 # Python3 >>> count ^ ^ ^ ╚═╩═╩═ Al consultar el valor de "count", este quedó intacto a pesar de for ╔══════════════════════════════════════════════════════════════════════════╩═╝ v -10 </code></pre> Como se puede apreciar, las variables utilizadas para iterar dentro de una lista de compresión tiene reservado un espacio aparte en memoria para que no modifiquen nuestro scope actual. Aunque en el ejemplo solo se hizo con listas de compresión, este principio funciona identico en diccionarios, generadores y sets de compresión.</p> Comparaciones de tipos de datos sin sentido (cof cof JS)</h2> O si, quizás una de las cosas que mas me molestan de Javascript estaba presente en Python2 y es la increíble comparación de tipos sin sentido, ya que, el lenguaje nos dejaba comparar una tupla con un str, o una lista con un diccionario, pero no estaba claro si era la longitud, la cantidad de memoria que necesitaba o simplemente la posición en el stack (por poder, podía ser cualquier cosa). las imágenes hablan por si mismas.</p> # python2 >>> (1, 2) > "123" True >>> [1, 2] > "123" >>> {1, 2, 3} >= 666 True >>> 123 > "¿Esto tiene algún sentido? .-." ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═ Pregunta ╔═╦═╦════════════════ Respuesta v v v False # Python3 >>> (1, 2) > "123" --------------------------------------------------------------------------- ... TypeError: '>' not supported between instances of 'tuple' and 'str' >>> [1, 2] > "123" --------------------------------------------------------------------------- ... TypeError: '>' not supported between instances of 'list' and 'str' >>> "foo" > {"a": 11, "b": lambda x: x**2} --------------------------------------------------------------------------- ... TypeError: '>' not supported between instances of 'str' and 'dict' </code></pre> Aquí ni pondré anotaciones en el código, creo que es bastante autodescriptivo... una autentica masacre a la razón.</p> print - función vs palabra reservada</h2> La función print</code> es quizás una de mas cosas que primero nos enseñamos a usar al momento de estar aprendiendo a utilizar Python. Y digo función solo refiriéndome a a Python3, ya que en Python2 print</code> era en realidad una palabra reservada, esto a priori debería de ser muy irrelevante para muchas personas, pero implicaba toparse con pared tarde o temprano ya que las funciones otorgan características interesantes de las cuales Python2 se estaba perdiendo, tal como elegir con que caractér terminará nuestra impresión, o con que caractér unirá el conjunto de datos que le arrojemos a la función.</p> # Python2 >>> print 123 ^ ^ ╚═══╩═ Al ser una palabra reservada no necesita paréntesis 123 >>> print "CodigoComentado" CodigoComentado >>> print("123", "456", sep="") ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═ Si se intenta utilizar como función, dará error File "<stdin>", line 1 print("123", "456", sep="") from __future__ import print_function ^ ^ ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═╩═╩═ Se puede importar la función "print" moderna >>> print("123", "456", sep="") 123456 >>> print "Hola mundo" ^ ^ ╚════════════╩═ Pero al hacerlo ya no podremos utilizar la sintaxis anterior File "<stdin>", line 1 print 123 # Python3 >>> print(123) 123 >>> print("CodigoComentado") Codigocomentado >>> print("Codigo", "Comentado", sep="-", end="\n=============\n") ^ ^ ^ ^ ╚═╩══════╩═╩═ "print" al ser una función por defecto, se le pueden pasar parámetros como a cualquier otra función Codigo-Comentado ============= </code></pre> El equipo de Python incluyó en Python2 un parche como paquete llamado __future__</code> en el que incluian un montón de caracteristicas de Python3 para llevarlas a Python2, entre ellas incluye a print</code> como función. Un movimiento muy inteligente por parte del equipo. A pesar del incoveniente de tener que hacer el import en todos los archivos, era mucho mejor que tener chapuzas con el sys.stdin</code> y nuestra implementación pobre del print</code>, sin contar que además ahora a print</code> la podiamos pasar como parámetro como cualquier otra función.</p> Unicode por defecto</h2> Y ahora el mejor y mi cambio favorito de todos. ¿Quién no llegó a sufrir por intentar meter una tilde al código de Python?, ¿O por leer un archivo que en su interior tuviera una ñ</strong>? que yo desde luego si, y es que Python2 no era unicode por defecto, sino que utilizaba el antigüisimo "ascíi" como estándar de codificación. Y es que en la época que Python2 nació, era de la mas común encontrarse con "ascii" por todos lados, pero esa época ya pasó y era necesario para todos que este hermoso lenguaje estuviera adaptado a las necesidad de un mundo globalizado. Python en realidad nunca se ha llevado demasiado bien con los tipos de datos que tienen que almacenar textos, pero por lo menos en Python3 esta tarea se hizo menos tortuosa teniendo unicamente 2 tipos de datos con tareas muy claras, el str</code> y los bytes</code>, a diferencia de python2 que teníamos el str</code>, el unicode</code> y el bytes</code> que en realidad era solo un apodo cutre para str</code>. ¿Todo muy confuso cierto? y es que en Python si queríamos manipular un str</code> que almacenara caracteres que estaban fuera del dominio de "ascii", debíamos decodificarlo a "utf-8" para convertirlo de str</code> a unicode</code>, pero aparte se debía poner al inicio de nuestro archivo .py</code> el shebang</em> # -*- coding: utf-8 -*-</code> para así manipular textos no-anglosajones con libertad.</p> # Python2 # -*- coding: utf-8 -*- ^ ^ ^ ╚═╩═╩═ Shebang indicando que manipularemos caracteres utf-8, no lo olvides a = "ñ" >>> a ^ ╚═ La inofensiva "ñ" es en realidad "\xc3\xb1" en ascii. ╔═════════════════════════════════════════╩═╩═╩═╝ v '\xc3\xb1' >>> type(a) ^ ^ ^ ^ ╚═╩═╩═╩═ La variable es de tipo "str" ╔═╦═══════════════════════════╩═╝ v v <type 'str'> a = a.decode("utf-8") ^ ^ ^ ╚═╩═╩═ Se decodifica a "utf-8" >>> a ^ ╚═ Y ahora la variable si guarda el valor correcto de la "ñ" en unicode ╔═══════════════════════════════════════════════════════════════════╩═╩═╩═╝ v u'\xf1' >>> type(a) <type 'unicode'> ^ ^ ^ ^ ╚═╩═╩═╩═ Otro tipo de dato para los strings con caracteres fuera de "ascii" >>> bytes == str True ^ ^ ╚═╩═ El tipo "bytes" es solo una broma de mal gusto en python2 ya que es solo un alias para el tipo "str" # Python3 a = "ñ" >>> a ^ ╚═ La "ñ" es una "ñ", correcto ╔════════════════════╝ v 'ñ' >>> type(a) ^ ^ ^ ^ ╚═╩═╩═╩═ El tipo de dato es "str", correcto ╔═╦═════════════════════════════╩═╝ v v 'str' a = a.encode("utf-8") ^ ^ ^ ╚═╩═╩═ Se codifica con el estandar "utf-8" para utilizar a "ascíi" >>> a ^ ╚═ Valor real en ascíi, correcto ╔═╦═╦═╦════════════╩═╩═╝ v v v v b'\xc3\xb1' >>> type(a) ^ ^ ^ ^ ╚═╩═╩═╩═ Ahora el tipo de dato es uno llamado "bytes" que solo almacena textos con caracteres en ascii ║ ║ ║ ╔═╦═╦══════════════════════════════════════════════╩═╩═╝ v v v bytes >>> bytes == str False ^ ^ ^ ╚═╩═╩═ El tipo "bytes" ahora si es distinto a "str" y no solo una fachada </code></pre> Como podemos darnos cuenta, en Python2 todo era mucho mas caótico al momento de manipular textos. Por suerte en Python3 todo quedó en solo 2 tipos con funciones bastante claras: El tipo str</code> será el encargado de almacenar todo tipo de textos y es compatible por defecto con el estandar utf-8</code> (utf-8 = emojis[😂, 😅, 🤔, 🔥, 💯, 🦆]) y el tipo bytes</code> será el encargado de almacenar cadenas de textos que solo deban</strong> almacenar caracteres ascíi, es decir, unicamente binarios. Como anecdota, recuerdo en cada archivo de Python3 que creaba, debía escribir al inicio:</p> try: unicode except: unicode = str </code></pre> para que el archivo no tuviera problemas para correr tanto en Python2 como en Python3 y poder utilizar a unicode</code> como tipo de dato para compararlo con isinstance</code>.</p> Conclusión</h2> Si bien Python2 fue una de las mejores cosas que le pasaron a mi vida en esta década y con la que aprendí realmente a programar y todo lo que envolvía al mundo de las ciencias de la computación, puedo decir con completa convicción... que bueno que vas a morir, no te extrañaré. Hasta nunca, Python2.</p> Fuentes</h2> https://docs.python.org/3/howto/pyporting.html</a></li> https://python-future.org/compatible_idioms.html</a></li> https://sebastianraschka.com/Articles/2014_python_2_3_key_diff.html</a></li> Experiencia personal</li> </ol> Actualizaciones</h4> 27-12-2019</strong>: Al parecer el EOL de Python2 no será en Enero, sino hasta Abril</a>. creo que quieren hacer coincidir la muerte de Python2 con la PyCon 2020 para hacerle un funeral con todos los asistentes o yo que se... de verdad, déjenlo morir, ya está agonizando. Otro tema diferente a tratar sería ver hasta cuando retirarán a Python2 de los repositorios de la N distribuciones *NIX... Gracias @irl_ry</a>. 28-02-2020</strong>: Arreglados algunos typos. Gracias VMS.</p> Manejo de excepciones en Rust Fri, 20 Dec 2019 09:05:15 GMT Uno de los temas que mas me ha costado aprender en Rust ha sido la manera de manejar los posibles errores que se puedan tener en tiempo de ejecución ya que, a diferencia de los demás lenguajes que ya había manejado (Python, Ruby o Java) ya que el concepto de "excepción" no existe como tal, sino que todo se trabaja mediante "panic!", "Option" y "Result" y unos métodos unwrap</code> o unwrap_or</code> y en este post explicaré cada uno de ellos.</p> panic!</h2> panic!</code> es un macro (no entraré en la definición de macro en este momento, esto será para una futura entrada. Pero para fines prácticos, es algo parecido a una función) que lo que hace es terminar con el hilo principal de ejecución de manera completamente abrupta y es imposible evitar su comportamiento. Así que nuestro objetivo es intentar tener el menor número de ejecuciones de panic!</code>, en la medida de lo posible, y solo ejecutarlo cuando sea 100% necesario. Es imposible de detener porque a nivel de ensamblador se está mandando llamar a la instrucción ud2</code> la cual genera un código de ejecución inválido y eso detiene en seco el hilo principal.</p> // Rust fn main() { panic!(); } ; Ensamblador ... example::main: push rax lea rdi, [rip + .L__unnamed_9] lea rdx, [rip + .L__unnamed_10] mov rax, qword ptr [rip + std::panicking::begin_panic@GOTPCREL] mov esi, 14 call rax ud2 ^ ^ ╚═╩═ Generación de un código inválido ejecución ... </code></pre> Su funcionamiento es de lo mas sencillo y tiene un cierto parecido a la función sys.exit</code> de Python, solo que el macro panic!</code> acepta un str</code> como parámetro para indicarle al usuario cual fue el posible error y este es opcional.</p> // Código fn main() { panic!(); } // Salida ... thread 'main' panicked at 'explicit panic', src/main.rs:2:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. // Código fn main() { panic!("Error en la función 'main'"); } // Salida ... thread 'main' panicked at 'Error en la función 'main'', src/main.rs:2:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. </code></pre> Option</h2> Ahora si comenzamos con el manejo de excepciones como tal. Option es un Enum</code> (Si no estás familiarizado con el término "Enum" pero si con el término "Tipo", en tu mente reemplaza uno por otro, para este caso son parecidos) que puede contener 2 posibles valores mutuamente excluyentes, y son "algún valor" o "ninguno", que traducido a lenguaje Rust sería un Some</code> o un None</code>. Este Enum</code> se tendrá que usar cuando nuestra función es posible que devuelva un valor o que no devuelva nada. La declaración en el campo a retornar es muy simple, solo se debe indicar que la función retornará una instancia del Enum Option</code>, un diamante (<></code>) y dentro del diamante el tipo de datos del posible valor a retornar. El valor a retornar debe estar "encapsulado" dentro de otro Enum llamado Some</code> y el dato dentro de ella debe ser del mismo tipo que la declarada dentro del diamante en la cabecera de la función.</p> fn factorial(n: i32) -> Option<i32> { ^ ^ ^ ^ ^ ║ ║ ║ ╚═╩═ Tipo de dato del posible valor a retornar ╚═╩═╩═ Nombre del Enum if n < 0 { None ^ ^ ╚═╩═ Se retorna el Enum "None" cuando no se retorna un valor } else if n == 0 { Some(1) ^ ^ ^ ║ ║ ╚═ Valor que se retornará ╚═╩═ Enum Some } else { let mut total = 1; for value in 1..n { total *= value; } Some(total) ^ ^ ^ ^ ^ ║ ║ ╚═╩═╩═ Valor que se retornará ╚═╩═ Enum Some } } </code></pre> Como se puede ver en el ejemplo, la función factorial</code> puede recibir un parámetro del tipo i32</code> y retornará un posible valor cuyo tipo de dato será también i32</code> y dentro de la función se retornan el Enum None</code> en caso de que no se deseé retornar ningún valor, o un Enum Some</code> cuando la función deba retornar un valor. simple, eh? Ahora vamos a ver como lidiar con lo que retorne esa función. Una de las maneras mas sencillas de trabajar con los Option es con la estructura de control match</code>, poniendo las posibles opciones como criterios de coincidencia dentro. Aquí un ejemplo:</p> fn factorial(n: i32) -> Option<i32> { ... } fn main() { let valor = factorial(10); ^ ^ ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═╩═╩═ Llamada a la función "factorial" match valor { Some(1) => println!("Posible factorial de 0 o 1"), ^ ^ ^ ║ ║ ╚═ Criterio de coincidencia exacto ╚═╩═ Enum Some Some(n) => println!("El factorial es: {}", n), ^ ^ ^ ║ ║ ╚═ Criterio de coincidencia con un identificador ║ ║ Se puede acceder a el desde el bloque de ejecución ╚═╩═ Enum Some None => println!("No se puede sacar el factorial de un número negativo"), ^ ^ ╚═╩═ Enum None } } </code></pre> Como se puede ver en el ejemplo, utilizando match</code> se pueden declarar los posibles criterios de coincidencia, ya sea con valores (Some(1)</code>) para que solo se ejecute el bloque si la función retorna explícitamente un Some</code> con valor "1". O también con una variable Some(n)</code> y esa variable se puede utilizar dentro del bloque a ejecutar y su Scope no va mas allá. Y por último también se puede hacer la coincidencia con el Enum None</code> cuando la función no deba retornar nada. Como podemos ver, la utilización del Enum Option</code> es una manera mas elegante de hacer cosas hacky</em> como devolver un "-1" cuando una función puede devolver un valor numérico.</p> Result</h2> Result</code> es otro Enum que tiene cierto parecido a Option</code> pero con una ligera diferencia y es que se debe retornar un Result</code> cuando la función deba retornar un error por culpa de alguno de los parámetros introducidos. Para indicar que una función retornará un Result</code> se debe colocar en la cabecera de la función el nombre del Enum Result</code>, un diamante y dentro del diamante 2 tipos de datos, el primero corresponderá al tipo de dato de una respuesta exitosa y el segundo corresponderá al tipo de dato de la respuesta errónea. Los valores a retornar deberán ser "encapsulados" en el Enum Ok</code> y en el Enum Err</code> y debe corresponder al tipo de dato correspondiente al colocado dentro del diamante. Como por ejemplo:</p> fn div(num1: i32, num2: i32) -> Result<f64, &'static str> { ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ║ ║ ║ ║ ║ ╚═╩═╩═╩═╩═╩═ Tipo de dato del error ║ ║ ║ ╚═╩═ Tipo de datos para el caso de éxito ╚═╩═╩═ Nombre del Enum if num2 == 0 { Err("No se puede dividir un número entre 0") ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ║ ║ ╚═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═ Valor que retornará como error ╚═╩═ Nombre del Enum } else { Ok(num1 as f64 / num2 as f64) ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ║ ╚═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═ Valor que retornará en caso de éxito ╚═ Nombre del Enum } } </code></pre> Como se puede ver en el ejemplo, en la cabecera de la función, en la parte donde se especifica que va a retornar, se debe colocar el Enum Result</code> y dentro de un diamante los 2 tipos de datos, en este caso será un f64</code> para los casos de éxito y un &'static str</code> (str estático) para los casos erróneos y dentro de la propia función se "encapsulan" los posibles valores de retorno en los Enum Ok</code> y Err</code> para los casos de éxito y de error según correspondan. Ahora, la manera de lidiar con el valor de una función que retorna un Result</code> es muy similar a la manera de tratar con los Enum Option... con un </code>match` y dentro, todas los posibles criterios de coincidencia.</p> fn div(num1: i32, num2: i32) -> Result<f64, &'static str> { ... } fn main() { let valor = div(10, 2); ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═ Llamada a la función "div" match valor { Ok(3.14159) => println!("wow, tu división retorna el número pi"), ^ ^ ^ ^ ^ ║ ╚═╩═╩═╩═ Criterio de coincidencia exacto ╚═ Enum Ok Ok(n) => println!("El resultado es: {}", n), ^ ^ ║ ╚═ Criterio de coincidencia con un identificador ║ Se puede acceder a el desde el bloque de ejecución ╚═ Enum Ok Err(e) => println!("{}", e), ^ ^ ^ ║ ║ ╚═ Criterio de coincidencia con un identificador ║ ║ Se puede acceder a el desde el bloque de ejecución ╚═╩═ Enum Err } } </code></pre> Se manda a comparar el valor retornado por la función utilizando un match</code> y los criterios deben ser los Enum Ok</code> con un valor exacto, con una variable que se puede utilizar dentro del bloque de ejecución o el Enum Err</code> que sigue las mismas reglas, se puede poner un valor exacto o una variable para utilizar dentro del bloque de ejecución.</p> pro-tip 1:</h4> Si por algún motivo no te interesa el valor retornado dentro del Ok</code>, Err</code> o Some</code> puede poner como identificador un "_</code>", así el compilador ignorará ese valor por completo y será un criterio de coincidencia válido, como por ejemplo:</p> fn div(num1: i32, num2: i32) -> Result<f64, &'static str> { ... } fn main() { match div(10, 0) { Ok(_) => println!("La división se ejecutó correctamente"), ^ ^ ║ ╚═ Criterio de coincidencia con "_" ║ El identificador al ser un "_", el valor nunca es guardado en memoria y es inaccesible ╚═ Enum Ok Err(_) => println!("Error ejecutando la división"), ^ ^ ^ ║ ║ ╚═ Criterio de coincidencia con "_" ║ ║ El identificador al ser un "_", el valor nunca es guardado en memoria y es inaccesible ╚═╩═ Enum Err } } </code></pre> pro-tip 2:</h4> Para mantener mas elegante nuestro código, es recomendable no retornar str's en los mensajes de error de los Result</code>, es mucho mejor implementar Enum's propios para cada posible error.</p> enum MathError { ZeroDivision, Domain } fn div(num1: i32, num2: i32) -> Result<f64, MathError> { ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═ Nombre de la estructura que contiene los posibles errores if num2 == 0 { Err(MathError::ZeroDivision) ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═ Valor dentro del Enum que contiene nuestro error deseado } else { Ok(num1 as f64 / num2 as f64) } } fn main() { match div(10, 0) { Ok(n) => println!("El resultado es: {}", n), Err(MathError::ZeroDivision) => println!("Oh no!, División entre 0"), ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═ Criterio de coincidencia más explícito para los errores _ => println!("Error desconocido"), ^ ╚═ Como nuestro Enum de errores tiene mas de un valor aparte del "ZeroDivision", se debe declarar una opción por defecto como criterio de coincidencia } } </code></pre> Los métodos unwrap</h2> Los match</code> son maneras muy elegantes para manejar los Option</code> o los Result</code>, pero en algunas ocasiones quizás querremos lidiar con ellos de una manera menos verbosa y justo para ese motivo existe la gama de métodos unwrap</code>. El comportamiento de los métodos unwarp</code> dependerá si el Option</code> o el Result</code> tiene un resultado exitoso y son los siguientes:</p> Nombre del método</th> Comportamiento</th> Ejemplo</th> </tr> </thead> unwrap</code></td> Intenta obtener el valor encapsulado dentro de un Some</code> o un Ok</code>. Sí la función no devolvió alguno de ellos y se ejecutará el macro panic!</code>. No recibe parámetros.</td> let valor = factorial(1).unwrap(0);</code></td> </tr> unwrap_or</code></td> Intenta obtener el valor encapsulado dentro de un Some</code> o un Ok</code>. Si la función devolvió un None</code> o un Err</code>, la función devolverá el valor pasado como parámetro que deberá ser del mismo tipo de dato declarado en el diamante para el caso de éxito. Recibe como parámetro el valor a devolver.</td> let valor = div(10, 0).unwrap_or(0f64);</code></td> </tr> unwrap_or_else</code></td> Intenta obtener el valor encapsulado dentro de un Some</code> o un Ok</code>. En caso de que la función haya devuelto un None</code> o un Err</code> la función retornará el valor que devuelva el closure</code> pasado como parámetro. Recibe como parámetro el closue</code> a ejecutar, en caso de que la función retorne un Result</code>, el closure deberá tener un argumento y si retorna un Option</code> el closure no debe tener argumentos.</td> let valor = factorial(-1).unwrap_or_else(|| 0); let valor = div(10, 0).unwrap_or_else(|_| 0f64);</code></td> </tr> unwrap_or_default</code></td> Intentará obtener el valor encapsulado dentro de un Some</code> o un Ok</code>. Si el valor fue ninguno o un error, el método retornará los valores por defecto de cada tipo de dato. No recibe ningún parámetro.</td> let valor = factorial(0).unwrap_or_default();</code></td> </tr> expect</code></td> Intenta obtener el valor encapsulado dentro de un Some</code> o un Ok</code>. Si la función retornó un None</code> o un Err</code>, el método mandará a llamar al macro panic!</code> con el mensaje que se le pase como parámetro. Recibe un parámetro del tipo "str"</td> let valor = div(0, 0).expect("Oh no");</code></td> </tr> </tbody> </table> Espero que les haya gustado y que les haya servido la información aquí proporcionada. Pueden comentarme mediante mi twitter @kirbylife</a> si algo de lo aquí leído es incorrecto o confuso. Con gusto los leeré :).</p> Fuentes</h2> https://doc.rust-lang.org/std/result/enum.Result.html</a></li> https://doc.rust-lang.org/std/option/enum.Option.html</a></li> The Rust programming language. Por Steve Klabnik y Carol Nichols.</a></li> https://rust.godbolt.org</a> (para traducción de código Rust a ensamblador).</li> https://learning-rust.github.io/docs/e3.option_and_result.html</a></li> </ol> Actualizaciones</h4> 23-12-2019</strong>: Arreglados algunos typos. Gracias Nacho. 28-02-2020</strong>: Arreglados algunos typos. Gracias VMS. 17-06-2020</strong>: Arreglado un typo. Gracias Marc</a>.</p> Nuevas características de python 3.8 Fri, 13 Dec 2019 08:10:07 GMT Hace un par de meses el equipo que está detrás de Python anunció una nueva subversión de Python3 llamada python3.8. En esta nueva subversión de incluyeron unas cuantas características y algunas de ellas me parecieron especialmente interesantes entre las cuales se encuentran:</p> 1) Expresiones de asignación</h2> Esta fue, quizás, la característica que mas me hace ilusión ya que por fin tenemos una manera elegante</em> de poder la operación la cual denomino "asignar y retornar". En una gran cantidad de lenguajes de scripting (PHP, JS, Ruby por poner un ejemplo) es común ver que la operación de asignación también retorna el valor que estamos asignando y en Python esto no ocurría. Para ello, el equipo de Python decidió implementar un nuevo operador :=</code>... Es idéntico al operador al operador de asignación de Go, pero su funcionamiento es muy distinto. Observen que es lo que sucede cuando usamos el clásico =</code> y el nuevo :=</code>:</p> > var1 = 10 <══ La operación de asignación no retorna nada > (var2 := 20) ^ ╚══ Nuevo operador 20 <══ La nueva expresión de asignación retorna el valor asignado a la variable "var2" </code></pre> Como se puede ver en el ejemplo, su funcionamiento, en principio, es idéntico al operador de asignación de toda la vida, lo único que cambió es que ahora como resultado de la operación, el interprete retorna lo asignado en la variable. Ahora que ya está todo claro seguramente se preguntarán "Y esto ¿qué uso práctico tiene?", bueno, a juzgar por la documentación oficial[2] su implementación se debe a que ahorita en el lenguaje se escriben demasiados while True:</code> e if's</em> con una variable justo arriba. . Aquí algún ejemplo práctico que se me ocurre a mi y otro que se puede encontrar en la documentación:</p> meter números a una lista y parar cuando se introduzca un 0</h3> # Ahora lista = [] while x := int(input()): ^ ^ ║ ╚══ Nuevo operador de asignación ╚════ Variable a la cual se le asignará el valor lista.append(x) # Antes lista = [] while True: x = int(input()) if not x: break lista.append(x) </code></pre> En este primer ejercicio se puede ver claramente como se redujo el número de lineas pasando de 6 a unicamente 3 mejorando el rendimiento pues solo es necesario hacer una comparación (la del while</code>) en lugar de 2 (la de while</code> que siempre iba a dar True</code> y la de if</code> para romper el ciclo) sin perder legibilidad en el código.</p> Sumar zona horaria (Ejemplo extraído de la documentación oficial)</h3> # Ahora s = _format_time(self._hour, self._minute, self._second, self._microsecond, timespec) if tz := self._tzstr(): ^ ^ ║ ╚══ Nuevo operador de asignación ╚════ Variable a la cual se le asignará el valor s += tz return s # Antes s = _format_time(self._hour, self._minute, self._second, self._microsecond, timespec) tz = self._tzstr() if tz: s += tz return s </code></pre> En este otro ejemplo extraído de la documentación oficial se puede ver como se evita declarar variables antes del if</code> para reducir la cantidad de lineas sin tener perjudicar a la legibilidad del código.</p> 2) Argumentos unicamente posicionales</h2> Este cambio, a diferencia del anterior, lo veo como una mejoría unicamente a nivel de "belleza"</em> del código, ya que esto no se verá reflejado al momento de que el código esté siendo interpretado. El cambio consiste en que ahora se podrá hacer que las funciones y métodos acepten los argumentos obligatoriamente en orden... ¿Esto con qué fin? unicamente estético a nivel de código y eso conlleve en una tortura mas ligera al momento de darle mantenimiento a código legacy (En el futuro claro, ahorita el código legacy seguramente estará escrito en python2). Para ello unicamente tendremos que colocar un /</code> después de los argumentos que tendrán un orden obligatorio, aquí unos ejemplos:</p> Función para elevar un número al cuadrado</h3> def pow(num, exp, /): ^ ╚══ Parámetro "/" para indicar argumentos Unicamente posicionales return num ** exp # Uso correcto >>> pow(5, 2) 25 >>> pow(exp=2, num=5) Traceback (most recent call last): ... TypeError: pow() got some positional-only arguments passed as keyword arguments: 'num, exp' >>> pow(num=5, exp=2) Traceback (most recent call last): ... TypeError: pow() got some positional-only arguments passed as keyword arguments: 'num, exp' </code></pre> Como se puede apreciar en el ejemplo, arroja un error cuando mandamos llamar a la función utilizando los nombres de los parámetros, aunque intentemos pasarlos en el orden que fueron declarados en un principio. Pero aquí no acaba la cosa, ya que posterior a la /</code> podremos declarar mas parámetros y estos volverán a tener el comportamiento habitual como en versiones anteriores de Python.</p> Sacar la edad de una persona y saludarla</h3> from datetime import datetime def say_hello(year, month, day, /, first_name, last_name): ^ ╚══ Parámetro "/" para indicar argumentos Unicamente posicionales date = datetime(year, month, day) diference = datetime.now() - date years = int(diference.days // 365.25) print(f"hello {first_name} {last_name} you're {years} years old") >>> say_hello(1810, 11, 23, "foo", "bar") hello foo bar you're 208 years old >>> say_hello(1910, 5, 4, last_name="foo", first_name="bar") hello bar foo you're 109 years old >> say_hello(day=28, month=7, year=2013, first_name="python", last_name="3.8") Traceback (most recent call last): ... TypeError: say_hello() got some positional-only arguments passed as keyword arguments: 'year, month, day' </code></pre> Como nos podemos dar cuenta, en la cabecera de la función los parámetros first_name</code> y last_name</code> están después de la /</code> y solo por eso ya se pueden utilizar de la manera antigua pudiendo asignarlos utilizando su nombre (ver caso 2).</p> 3) Especificador "=" en f-strings</h2> Este cambio me parece buenísimo y es muy fácil de explicar y rápido de entender, se trata de que ahora las operaciones que hagamos dentro de un f-string las podremos poner dentro del propio f-string sin tener que escribir 2 veces la misma operación.</p> # Ahora >>> print(f"{10+5=}") ^ ╚══ Signo "=" para indicar que es una expresión de debugeo 10+5=15 >>> print(f"{10+5-22/34**55//5=}") ^ ╚══ Signo "=" para indicar que es una expresión de debugeo 10+5-22/34**55//5=15.0 >>> print(f"{(a:=10)=} \t {10*a=}") ^ ^ ╚══════════╩══ Signo "=" para indicar que es una expresión de debugeo (a:=10)=10 10*a=100 # Antes >>> print(f"10+5={10+5}") 10+5=15 >>> print(f"10+5-22/34**55//5={10+5-22/34**55//5}") 10+5-22/34**55//5=15.0 </code></pre> Como pueden apreciar en el caso 3, se pueden declarar variables DENTRO</em> del propio f-string gracias a nuestro precioso operador :=</code> y se visualizará exactamente como lo hayamos escrito. Para debugear con print's esto será una genialidad.</p> 4) Nuevas validaciones para tipos de datos</h2> Como bien sabemos, en Python existen una buena cantidad de herramientas para ESPECIFICAR</em> (mas no validar) algunas pautas que el programador debe seguir al momento de estar de estar escribiendo su código. Estas pautas realmente no le dicen nada al interprete cuando nuestro programa se está ejecutando, solo sirve para que el linter (si lo soporta) nos arroje ciertos errores cuando estamos escribiendo código. En python3.8 incluyeron algunas nuevas características para marcar mas pautas y son las siguientes:</p> 4.1) Calificador "final"</h3> El paquete typing</code> incluye una gran cantidad de herramientas para escribir unas pautas mas "estrictas" (estrictas entre comillas, ya que realmente al interprete le dan completamente igual). Entre esas características, en Python3.8 incluyeron un nuevo calificador (que así es como le llaman a las pautas) que permite decir de cual clase NO deberíamos heredar, cual método NO deberíamos sobrescribir, cual método SI deberíamos sobrescribir y cuales atributos NO deberíamos modificar. Para ello incluye un decorador y un tipo de dato, su uso es el siguiente: Las clases de las cuales no deberíamos heredar ahora se deberían decorar con @final</code> como en el siguiente ejemplo:</p> Decorando clases</h4> from typing import final @final <══ Decorando la clase con el decorador "final" del paquete "typing" class Base: pass class A(Base): ^ ^ ╚═╩═ Utilizando la clase "Base" para heredar de ellas pass </code></pre> Como he repetido anteriormente, esto solo es una validación a nivel de linter y para una auto-documentación mas explícita ya que al ejecutar el código anteriormente descrito, este no presentará error alguno a nivel de interprete. El linter debería arrojar un error.</p> Decorando métodos</h4> from typing import final class Base: @final <══ Decorando el método con el decorador "final" del paquete "typing" def method_1(self): pass class A(Base): def method_1(self): ^ ^ ^ ^ ╚═╩═╩═╩══ Reescribiendo un método decorado con "final" en la clase padre pass </code></pre> Esto también debería arrojar un error al momento de ser inspeccionado por un linter. Pero repito, el interprete nos dejará sobrescribir estos métodos sin ningún mensaje de error.</p> Declarando atributos</h4> from typing import Final ^ ^ ^ ╚═╩═╩═ Importando el tipo "Final" (Con "F" mayúscula) del paquete "typing" var_1: Final = "Hello world" ^ ^ ^ ╚═╩═╩╦═╦═╦══ Declarando las variables de tipo "Final" ║ ║ ║ class Base: v v v attr_1: Final = 10 var_1 = "Good bye world" <═╦══ Intentado asignarle nuevos valores a variables Base.attr_1 = -1 <═╝ del tipo "Final" </code></pre> También esto puede aplicar para variables sueltas del programa o para atributos internos de una clase. Al declararlas del tipo Final</code> el linter debería arrojar un error cuando se intenten asignar nuevos valores.</p> Si quieres saber mas sobre decoradores puedes pasarte por mi entrada anterior</a>.</p> Conclusiones</h2> Estos no fueron todos los cambios, como dije al principio, solo fueron los que me parecieron mas útiles y que se podían explicar de una manera relativamente sencilla. Los otros eran mas cambios relacionados al multithreading y a la carga de información utilizando CPython... No digo que no sean irrelevantes esos cambios, solo que me quise centrar mas en cambios relacionados a cosas de sintaxis. Sin duda alguna mis cambios favoritos en esta versión fue el operador de asignación y retorno ya que, en mi opinión, hará posible la escritura de un código mas limpio. Puedes consultar todos los cambios en la sección de "Fuentes". Muchas gracias por leerme otro día mas.</p> Fuentes</h2> Changelog</a></li> Ejemplos de implementación de la expresión de asignación</a></li> Artículo oficial de Python sobre esta versión</a></li> </ol> Decoradores de python: una herramienta poderosa y desconocida Fri, 22 Nov 2019 21:54:07 GMT Los decoradores en Python son una gran herramienta que hacen que el código sea más fácil de mantener y que desgraciadamente no se le suele dar tanta importancia. Son la manera en la cual puedes reutilizar un mismo código para alterar el funcionamiento de funciones cuando este se vuelve muy repetitivo.</p> Si lo quieres ver de esta forma, los decoradores son a las funciones lo que las interfaces son a los objetos. O si vienes de un ambiente mas rubyista</em>, los decoradores son algo parecido a los bloques.</p> Los decoradores son básicamente la "trifecta" de las funciones ya que:</p> Son una función</li> Reciben una función</li> Retornan una función</li> </ol> Los habrás visto y/o usado seguramente si haz trabajado alguna vez con el framework web Flask</a> ya que es la manera recomendada que tiene este framework para crear rutas para tu servicio web.</p> @app.route("/") def index(): pass </code></pre> Sintaxis de una decorador</h2> Indicador de "decoración"</h4> @decorador(params) ^ ╚════ Caractér para indicar que decoraremos una función </code></pre> La manera mas sencilla para detectar que una función está siendo "decorada" es por que justo arriba de su cabecera se encuentra algo parecido a una llamada a una función pero que comienza con @</code>.</p> Nombre del decorador</h4> @decorador(params) ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩══ Nombre del decorador </code></pre> Esto es bastante simple y no varía en lo absoluto con una llamada típica a una función... para saber cual decorador estamos usando, se usará su nombre.</p> Argumentos del decorador</h4> @decorador(params) ^ ^ ^ ╚═╩═╩══ Parámetros para modificar el decorador (opcional) </code></pre> Tampoco esto varia demasiado con las funciones de toda la vida. Si el decorador acepta parámetros, se le pasan colocándolos dentro de unos paréntesis.</p> Cabecera de la función a decorar</h4> @decorador(params) def index(): ^ ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═╩══ Función a decorar </code></pre> Inmediatamente debajo del decorador se debe colocar la función que será decorada.</p> Decoradores sin parámetros: Funcionamiento interno</h2> Como mencioné al inicio del artículo, los decoradores no son otra cosa más que simples funciones.</p> def decorador(f): def wrap(*args, **kwargs): return f(*args, **kwargs) return wrap @decorador def funcion(x): return x**2 </code></pre> Esta es el decorador mas simple que se puede escribir... YYYYY no hace absolutamente nada, pero nos puede dar una idea de como están compuestos.</p> Estructura del decorador</h3> Nombre del decorador</h4> def decorador(f): ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩══ Nombre del decorador </code></pre> Es el nombre que recibirá el decorador y que luego utilizaremos con la sintaxis de @nombre</code>.</p> Función a decorar</h4> def decorador(f): ^ ║ ╚═╦═══ Función a decorar siendo @decorador ║ capturada por el decorador def funcion(x):<╝ </code></pre> Este parámetro que está recibiendo nuestra función/decorador es una referencia a la función que posteriormente se colocará debajo del decorador.</p> Función interna del decorador</h4> def decorador(f): def wrap(*args, **kwargs): ^ ^ ╚═╩════ Nombre provisional para uso interno del decorador </code></pre> Esta será la función que retornaremos, wrap</code> es solo un nombre provisional que usaremos unicamente dentro del decorador y que jamás se podrá ver al momento de utilizar el decorador.</p> Argumentos que fueron mandados a la función decorada</h4> def decorador(f): def wrap(*args, **kwargs): ^ ^ ^ ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═╩═╩═╩══ Nuevos argumentos que aceptará nuestra función </code></pre> Como nosotros al momento de crear el decorador desconocemos la cantidad real de argumentos que aceptará la función decorada, simplemente debemos capturar absolutamente todos para luego "desenvolvernos" al momento de llamar a la función a decorar.</p> llamada a la función decorada</h4> def decorador(f): def wrap(*args, **kwargs): return f(*args, **kwargs) ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═╩═══ Llamada a la función decorada desenvolviendo los parámetros capturados en el wrap </code></pre> Recordemos que en f</code> se encuentra una referencia a la función a la cual queremos decorar, eso significa que si mandamos llamar a la función f</code> realmente estaremos llamando a la función que colocamos debajo de nuestro decorador, y como esto es un decorador simple, no hacemos otra cosa mas que retornar los que la función decorada nos retorne.</p> Retorno de la nueva función generada</h4> def decorador(f): def wrap(*args, **kwargs): return f(*args, **kwargs) return wrap ^ ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═╩══ Se retorna una referencia a nuestra función provisional </code></pre> Aquí está el truco de todo esto ya que, como dije al principio, nuestro decorador está retornando una función, o mas bien, una referencia a nuestra función... así que cuando estamos llamando a una función decorada, realmente estamos mandando llamar a un impostor, a una función intermediaría entre nosotros y nuestra hermosa función.</p> Decorador listo</h4> def decorador(f): def wrap(*args, **kwargs): return f(*args, **kwargs) return wrap @decorador def funcion(x): return x**2 </code></pre> y boilá</em>, nuestro primer decorador está listo para ser coronar a nuestras funciones y otorgarle cualidades especiales... ...o en este caso, ninguna cualidad.</p> Decoradores con argumentos: Funcionamiento interno</h2> Pero si creíste que el viaje por este maravilloso mundo de decoradores, funciones retornando funciones e impostores había acabo, pues estás equivocado ya que ahora subiremos al siguiente nivel, hacer que nuestro decorador admita * Tambores dramáticos * parámetros. Los decoradores que reciben parámetros no son muy distintos a los decoradores que NO reciben parámetros, solo que con una pequeña diferencia. Si los decoradores que NO reciben parámetros son una función que retorna una función, los decoradores que SI reciben parámetros son funciones que retornan una función que retorna una función * emoji impactado *. Pero esto, por que es así? por que nosotros al estar pasándole parámetros a una función realmente estamos llamando a una función y como a nosotros lo que nos interesa es otra función, pues la función a la que llamamos nos debe retornar otra... Yo se que te estoy confundiendo mas de lo que te estoy ayudando, así que mejor vamos a ver un ejemplo.</p> def decorador(*args, **kwargs): def decorator(f): def wrap(*args, **kwargs): return f(*args, **kwargs) return wrap return decorator </code></pre> Aquí notamos algo familiar, no? def decorator</code> que recibe una función en su parámetro, un función cuyo nombres es wrap</code> que es retornado, pues si. En pocas palabras, podríamos decir que un decorador que SI recibe parámetros es un generador de decoradores que NO reciben parámetros. Genial, no? vamos a explicarlo un poco.</p> Cabecera del decorador recibiendo parámetros</h4> def decorador(*args, **kwargs): ^ ^ ^ ^ ^ ╚═╩═╩═╩═╩═══ Nombre de nuestro decorador </code></pre> Comenzamos nuevo, este será el nombre que usaremos en la sintaxis de @decorador</code> con la diferencia de que ahora nuestro decorador no recibe una función en sus parámetros, sino que recibe sus propios parámetros. Aquí es donde el decorador que flask que vimos al principio tiene declarados los argumentos como la ruta o los métodos. Pueden ser recibimos como argumentos envueltos con *args, **kwargs</code> o podemos recibirlo uno a uno como una función cualquiera, por ejemplo:</p> def decorador(arg1, args2="default value", arg3=None) </code></pre> y cuanta fantasía se nos vaya ocurriendo durante el proceso de programación. La otra parte del decorador es exactamente la misma que con los decoradores sin parámetros.</p> Como se puede apreciar, los decoradores no son mas que un juego entre recibir funciones y retornar funciones y esto se puede explotar hasta donde nuestra imaginación nos de. Pero la pregunta que quizá alguno de ustedes tengan es "¿Y eso que utilidad tiene?".</p> Utilidad</h2> Como pudimos ver en los 2 bloques anteriores, nosotros al crear un decorador tenemos total acceso tanto a las funciones, como a los argumentos que estas están recibiendo, lo cual puede dar juego a hacer toda clase de validaciones y registros.</p> Ejemplos</h2> A lo largo de mi vida como programador en Python he escrito bastantes decoradores y quiero compartir (y explicar) con ustedes un par de ellos.</p> Decorador para manejo de excepciones</h3> def try_catch(value=...): def decorator(f): def wrap(*args, **kwargs): try: return f(*args, **kwargs) except BaseException as e: if value is ...: return e else: return value return wrap return decorator @try_catch(0) def pow(num, exp): return num ** exp > pow(10, 2) 100 > pow(5, 5) 3125 > pow("foo", 10) 0 @try_catch() def pow(num, exp): return num ** exp > pow("foo", 10) TypeError("unsupported operand type(s) for ** or pow(): 'str' and 'int'") </code></pre> Como se puede apreciar, este es un decorador que si recibe parámetros, para ser correcto, recibe un solo parámetro y es opcional y el característica que le otorga a las funciones es la de evitar que arrojen una excepción y si lo hace, retornar el valor que se le pasó al decorador como parámetro y si no se le pasa ningún parámetro, retornará (mas no lanzará) la excepción que arrojó la función.</p> Decorador que revisa que todos los parámetros sean números</h3> def only_numbers(f): def wrap(*args, **kwargs): for arg in args: if not isinstance(arg, (int, float)): raise ValueError(f"{arg} is not an int or a float, is a {type(arg).__name__}") return f(*args, **kwargs) return wrap @only_numbers def suma(*args): return sum(args) > suma(1, 2, 3, 4, 5) 15 > suma(1, 2, 3, 4, "foo") --------------------------------------------------------------------------- ValueError Traceback (most recent call last) ... ValueError: a is not a int or a float, is a str </code></pre> Este otro decorador no recibe parámetros y lo que hace es verificar que todos los parámetros que esté recibiendo nuestra función sean tipo int</code> o tipo float</code>, de lo contrarío arrojará una excepción advirtiendo que uno de los argumentos incumple esta regla.</p> Bonus: Apilamiento de decoradores</h2> Una ultima cosa antes de terminar y como dato que hará que les vuele cabeza. Los decoradores también se pueden apilar al momento de ser utilizados decorando una función dando como resultado una herramienta verdaderamente poderosa para la reutilización de código. Los decoradores que puse de ejemplo no fueron al azar, pues los escogí exactamente por que se pueden apilar ya que uno es capaz de capturar excepciones y otro arroja una excepción, dando como resultado algo como:</p> @try_catch(-1) @only_numbers def suma(*args): return sum(args) > suma(1, 2, 3) 6 > suma(1, 2, "foo") -1 </code></pre> Muchas gracias por leer el primer post de mi blog, espero que les haya gustado. en mi twitter @kirbylife</a> pueden hacerme llegar las opiniones con respecto al post, que les pareció, en que puedo mejorar o si tengo algún error, tanto en el código como en la redacción.</p>

Implementación de instrucciones con template</h2>
Ya casi terminamos, solo nos faltan las instrucciones que utilizan parámetros y además utilizan la template, que son el `if</code> y el repeat</code>. Comenzaremos con este último, ya que es el más sencillo de implementar.</p>`

Rust en Arduino - La manera difícil

Crear función que retorne un array con N valores por defecto en Rust - Const Generics

Optimizando código en Python

Poetry: un gran gestor de proyectos para Python

Fuentes</h2>

https://python-poetry.org/docs/</a></li>
https://github.com/python-poetry/poetry/issues/728</a></li>
https://docs.pytest.org/en/latest/usage.html</a></li> </ol>

¿Por qué Python3 es objetivamente mejor que Python2?

Manejo de excepciones en Rust

Nuevas características de python 3.8

Fuentes</h2>

Changelog</a></li>
Ejemplos de implementación de la expresión de asignación</a></li>
Artículo oficial de Python sobre esta versión</a></li> </ol>

Decoradores de python: una herramienta poderosa y desconocida

Sintaxis de una decorador</h2>

Estructura del decorador</h3>

Utilidad</h2>
Como pudimos ver en los 2 bloques anteriores, nosotros al crear un decorador tenemos total acceso tanto a las funciones, como a los argumentos que estas están recibiendo, lo cual puede dar juego a hacer toda clase de validaciones y registros.</p>

Ejemplos</h2>
A lo largo de mi vida como programador en Python he escrito bastantes decoradores y quiero compartir (y explicar) con ustedes un par de ellos.</p>

Código Comentado

Creando un motor de plantillas ligero (y malo) en Python

funcionamiento de la generación de claves TOTP

Código Comentado

Creando un motor de plantillas ligero (y malo) en Python

Implementación de instrucciones simples</h2> Comenzaremos con las instrucciones que hacen las transformaciones de strings, esto para explicar mas o menos la idea detrás de todo esto ya que son las mas sencillas de implementar.</p>

Implementación de instrucciones con template</h2> Ya casi terminamos, solo nos faltan las instrucciones que utilizan parámetros y además utilizan la template, que son el if</code> y el repeat</code>. Comenzaremos con este último, ya que es el más sencillo de implementar.</p>

funcionamiento de la generación de claves TOTP

Rust en Arduino - La manera difícil

Crear función que retorne un array con N valores por defecto en Rust - Const Generics

Optimizando código en Python

Poetry: un gran gestor de proyectos para Python

Instalación</h2> La instalación es bastante sencilla y como única dependencia, debemos ya tener instalado Python en nuestro equipo.</p> Si nuestro equipo tiene alguna distribución de GNU/Linux, MacOS o es windows con bashonwindows, basta con ejecutar el comando:</p>

Sección extra: Posibles problemas</h2> Error [TooManyRedirects] al intentar añadir un nuevo paquete</h3> Para solucionarlo es muy sencillo, basta con limpiar el caché de Poetry así:</p>

Error [TooManyRedirects] al intentar añadir un nuevo paquete</h3> Para solucionarlo es muy sencillo, basta con limpiar el caché de Poetry así:</p>

¿Por qué Python3 es objetivamente mejor que Python2?

Manejo de excepciones en Rust

Nuevas características de python 3.8

Decoradores de python: una herramienta poderosa y desconocida

Sintaxis de una decorador</h2>

Estructura del decorador</h3>

Utilidad</h2> Como pudimos ver en los 2 bloques anteriores, nosotros al crear un decorador tenemos total acceso tanto a las funciones, como a los argumentos que estas están recibiendo, lo cual puede dar juego a hacer toda clase de validaciones y registros.</p>

Ejemplos</h2> A lo largo de mi vida como programador en Python he escrito bastantes decoradores y quiero compartir (y explicar) con ustedes un par de ellos.</p>

Implementación de instrucciones con template</h2>
Ya casi terminamos, solo nos faltan las instrucciones que utilizan parámetros y además utilizan la template, que son el `if</code> y el repeat</code>. Comenzaremos con este último, ya que es el más sencillo de implementar.</p>`

Utilidad</h2>
Como pudimos ver en los 2 bloques anteriores, nosotros al crear un decorador tenemos total acceso tanto a las funciones, como a los argumentos que estas están recibiendo, lo cual puede dar juego a hacer toda clase de validaciones y registros.</p>

Ejemplos</h2>
A lo largo de mi vida como programador en Python he escrito bastantes decoradores y quiero compartir (y explicar) con ustedes un par de ellos.</p>