fstrings.wtf

• fstrings.wtf es un cuestionario en línea para poner a prueba tu comprensión de la función f-string de Python
• Está compuesto por preguntas que evalúan los distintos comportamientos y casos de excepción de f-string aplicados en la versión más reciente, Python 3.13
• Los usuarios pueden empezar el cuestionario de inmediato sin ningún proceso adicional
• Permite experimentar de antemano con trucos o comportamientos inesperados relacionados con f-string que aparecen con frecuencia en el trabajo práctico

[GN⁺]

Comentarios de Hacker News

• La interpolación de cadenas es como la inferencia de tipos: una vez que te acostumbras, se siente muy incómodo no tenerla. Parece que mientras más se agrega gradualmente, mejor se vuelve, pero en algún momento te das cuenta de que el código termina siendo difícil de leer. En general, en CS uno quiere seguir agregando funciones, pero a veces eso es difícil desde el punto de vista matemático. Aquí hay que evitar tanto no tener nada como tener demasiado. Python y C# eligieron dejarlo al gusto del usuario. Puedes escribir una cadena de interpolación compleja de 16 páginas, pero a tus colegas puede no gustarles y podría no pasar code review. C++ 23 directamente adopta un estilo que prohíbe la interpolación desde el inicio. Rust eligió una opción muy restringida que solo permite interpolar identificadores, y para algunas personas eso puede sentirse insuficiente, mientras que para otras puede parecer excesivo

  • Creo que el equipo de Java String Template pasó por un proceso parecido. A simple vista parecía un sistema bastante elegante, pero al intentar usarlo sintieron que la dirección era inviable, así que terminaron quitándolo por completo. Considerando la demanda por la interpolación y todo el esfuerzo invertido hasta ahora, fue una decisión bastante interesante. Al final concluyeron que no había vuelta atrás y regresaron al punto de partida

  • La pureza y la practicidad entran en conflicto, y cada lenguaje termina encontrando un punto de equilibrio distinto. Como no hay una respuesta correcta, los desarrolladores repiten una y otra vez que cada quien tiene su propio criterio de qué es lo correcto

  • Cada vez que necesito formatear números o fechas en C#, termino buscando primero la documentación. Ese mini lenguaje es tan malo que decidí no memorizarlo

  • No me resultó difícil controlar la interpolación sin tener que ajustarla a ejemplos complejos. Nunca sentí la necesidad de anidar f-strings dentro de otras f-strings, y el único especificador de formato que uso seguido es :02x

  • No creo en absoluto que la forma restringida de interpolación de Rust sea una solución. Como solo funciona en ciertos casos, al refactorizar código tienes que estar pendiente todo el tiempo y terminas haciendo retoques innecesarios. Como mínimo, debería permitir acceso a campos. En cambio, en Python, aunque existan casos raros como los del ejemplo, a los usuarios reales no les importa y simplemente disfrutan usar f-string

• Hace poco me enteré de varios tips que explican en sitios como fstring.help (alineación centrada, prefijos 0x/0b/0o, representación ASCII, etc.). También me interesaba el tema de las f-strings anidadas, y hasta 3.11 era posible si solo cambiabas el tipo de comillas. Según entiendo, en 3.12 se limpiaron varias de esas restricciones. Las f-strings son cómodas, pero tener que alternar con frecuencia entre el viejo formateo con %, el estilo .format() y el nuevo estilo, con sus diferencias sutiles, es más engorroso de lo que parece, y hay muchas situaciones donde no se puede evitar. La usabilidad ha mejorado, pero sigue siendo una lástima cuando todavía hay que usar las formas antiguas

  • Se puede confirmar en la documentación oficial que en 3.12 se ordenó esta parte

  • A veces veo colegas o IA usando f-strings en llamadas a logger, pero logger tiene interpolación diferida precisamente porque fue diseñado así, y me sorprende que dejen pasar esa ventaja tan buena

  • Creo que las f-strings anidadas son más bien un problema tipo truco. Sabía que se iba a agregar la posibilidad de anidarlas usando el mismo estilo de comillas, pero no sabía en qué versión. Yo todavía uso el truco f'{f"{}"}' porque quiero que mi código siga siendo compatible con versiones un poco más antiguas de Python

• Me acabo de enterar de la función en f-string que imprime a la vez la expresión y su valor usando el signo igual (=)

  • Creo que las notas de lanzamiento de Python realmente valen la pena leerlas. Siempre hay sorpresas agradables. La función del signo igual se agregó en Python 3.8 enlace relacionado

  • Es una lástima que no se haya adoptado un PEP con una función parecida para los argumentos con nombre de las funciones. Si existiera una forma como foo(bar=) en vez de foo(bar=bar), sería más fácil distinguir cuándo simplemente se está pasando un argumento, y también sería útil para depuración

  • Me parece una función que, en comparación con lo mucho que sorprende, no aporta suficiente valor. Tiene mucho potencial de comportarse de forma inesperada, y me preocupa que se convierta en fuente de bugs. Tal vez sería mejor una función estándar que imprima solo parte de locals()

  • Es un patrón que se usa muchísimo en salidas de depuración. En C++ desarrollé la costumbre de poner una expresión entre comillas y la otra no. Hace que sea más fácil de entender y está bien porque no requiere pensarlo demasiado

  • Es realmente útil para depurar con print(f)

• A diferencia de lo que sugiere la URL, creo que casi no hay preguntas realmente de nivel WTF. Hay algunas verdaderamente sorprendentes, como las preguntas 20 y 21

  • Yo encuentro tan útil el walrus operator que jamás querría renunciar a él. Hace que el código quede mucho más limpio al manejar pattern matching y múltiples ramas. No lo uso tan seguido, pero en las situaciones adecuadas es muy efectivo

  • Esto no es por el walrus operator, sino por la forma en que funciona python string.format; ver la documentación relacionada

• Antes y después de la introducción de f-string no usé Python tan en serio, pero acerté casi todas las reglas de sintaxis, y de hecho solo me equivoqué varias veces en cosas relacionadas con el valor de retorno. Incluso pienso que f-string quizá sea una de las partes menos WTF de Python

• Mientras hacía una librería para Lua parecida a f-string, aprendí bastante de la sintaxis, pero no esperaba f"{...}" ni el walrus operator. Aun así, está lejos del nivel de rareza de Wat. La librería relacionada está aquí

  • Esa librería de verdad se ve genial

• No creo que haya nada especialmente digno de un WTF. Gran parte del contenido trata más bien de la sintaxis del mini lenguaje de str.format() que de f-string

  • Sí había algunas cosas dignas de WTF, pero la mayoría era más bien sobre si conocías o no la sintaxis de formateo de cadenas

• Parece que tiene demasiadas funciones y ya pasó el punto crítico. No hace falta que un solo desarrollador conozca todo, y como cada vez que realmente hay que usarlo toca buscar la documentación, termina siendo ineficiente. Como se usa poco, se olvida la sintaxis, y suele ser mucho más rápido implementar uno mismo la misma función, con la ventaja de que además es más fácil de personalizar para quien vea el código. ¿Padding a la izquierda? Con una función de 2 líneas basta. En vez de confundirme con la sintaxis de formateo (si n va antes o si < va antes, etc.), me resulta más rápido implementarlo ad hoc

  • Cosas como el padding a la izquierda también se pueden usar con el método string.format, y ese estilo ya existía desde Python 2.6 (lanzado en 2008); ver la documentación relacionada. A mí, al contrario, la sintaxis de formato se me queda bien en la cabeza y me resulta útil. Además, el formateo deja abierta la posibilidad de hooks para personalización

  • Yo preferiría un punto intermedio. Sería mucho más cómodo que funciones como pad_left/pad_right permitieran especificar directamente el carácter de relleno también como argumento con nombre. Como es algo que se necesita de vez en cuando en la vida diaria, estaría bien tenerlo en la biblioteca estándar. Si la biblioteca del lenguaje no trae algo así, al final cada proyecto termina lleno de implementaciones mediocres, como en JavaScript. En mis proyectos no creo necesitar formateos de Python como ^ o <>, pero en software donde la salida en “monoespaciado” es importante, eso sí puede ser una función muy importante

  • A veces en un mismo codebase se usan repetidamente muchas funciones raras o atajos. Suele pasar que se crea una vez, se copia y pega, y luego se sigue reutilizando

• Si esta sintaxis hubiera sido de JavaScript, la mayoría se habría quejado de que es una sintaxis poco intuitiva y llena de funciones raras

  • Yo creo que la verdadera idea de este quiz es que Python también tiene muchos footguns, no muy distinto de JavaScript. Quizá es porque en JS este tipo de posts de “WTF” aparecen seguido

  • Incluso dejando de lado los truquitos, creo que JavaScript sigue siendo por mucho el rey de la sintaxis poco intuitiva. Los elementos de f-string en Python también son peculiares, pero solo aparecen en situaciones específicas, mientras que en JS ni siquiera has terminado de comparar dos arreglos y ya estás esperando a que se instalen dependencias

  • Quisiera preguntar sobre los template literals de JavaScript. A diferencia de Python, parece que en JS no se puede hacer algo como let template = 'hello ${name}'; y luego rellenar dinámicamente valores varias veces con algo como template.format({ name: 'joe' }). Por eso no me quedó más que implementarlo yo mismo. También revisé cosas como tagged templates, pero me resultó difícil reutilizar la plantilla en sí. Entiendo totalmente las quejas sobre la sintaxis y las funciones raras de JS

  • Si hubiera sido Perl, al contrario, habría recibido puro elogio

• Uso pyformat.info (enlace) como referencia; no es extremadamente detallado, pero sí reúne casi todos los ejemplos razonables