La nueva versión de Python reduce casi a la mitad el consumo de CPU: las implicaciones energéticas son enormes

Hace unos días, la cuenta oficial en Twitter de PyPI (Python Package Index), el repositorio de software vinculado al lenguaje Python, publicaba la siguiente imagen, mostrando el nivel de consumo de CPU resultante de la ejecución de Gunicorn (un servidor web basado en Python), justo antes y después de ser actualizado a la nueva versión de Python, la 3.11.

[#1 MetalAgm]

https://www.xataka.com/aplicaciones/luz-esta-cara-que-averiguar-cual-lenguaje-programacion-eficiente-buena-idea

[#2 Desactivado]

Sería interesante saber qué cambios han hecho, a nivel de compilador y otros, para lograr eso.

[#3 exeware]

#2 si han reducido consumo sin reducir prestaciones pos si.

[#4 exeware]

#1 python era 79 veces peor que c, margen de maniobra había

[#5 Jakeukalane]

Manjaro hace poco iba por la 3.8 o la 3.9; no me imagino la cantidad de cosas que romperán al actualizar esta vez...

editado:

Parece que ya van por la 3.10 pero dudo que esa sea la situación con Ubuntu y Debian que son los sistemas usados en Google Colabs.

[#6 Cuñado]

#2 Pues más fácil no lo puedes tener

Precisamente, el release manager de la 3.11, y miembro de Faster CPython, es español y hace unos meses que dio una charla al respecto en la PyConEs sobre este tema:

[#7 Jakeukalane]

#5 Edit2. ¿EEE de Microsoft contra Python a la vista? Ya lo están haciendo con Linux.

[#8 abnog]

Si hiciesen lo mismo con Java solucionaríamos la crisis energética de un plumazo.

[#9 era_mi_primer_dia]

#4 ahora únicamente es 40 veces peor

[#10 Desactivado]

#6 “Release Manager” toma ya!

[#11 Rexor]

#2 no es muy normal compilar python, las mejoras habrán sido a nivel de intérprete

[#12 boikot]

#10 Yo ocupo la posicion de release manager en mi empresa , no se que ves de raro o asombroso. En grandes organizaciones es normal tener a alguien que tome el control de las releases de los distintos equipos / productos aunque vaya un poco en contra de la filosofia CI / CD.

[#13 Yengamatico]

#9 tambien es 40 veces mas rapido desarrollar en python que en c, con el ahorro de costes que supone

[#14 Desactivado]

#8 java es muchísimo más potente que Python

[#15 sillycon]

#3 dice también que es un 25% más rápido.
En cualquier caso Python es un lenguaje interpretado a través de un lenguaje intermedio, al estilo de los bytecodes de Java. Cualquier lenguaje compilado medianamente correcto será mucho más eficaz.

[#16 Desactivado]

#12 ¿pero sería masculino o femenino? ¿Las o los?

[#17 pawer13]

#8 Java sigue siendo más eficiente que Python. Gasta más RAM, pero menos CPU

[#18 wai]

#13 Mínimo. El desarrollo solo es un pequeño % en el tiempo de vida de un programa.

Si en vez de desarrollar en 100 horas tardas 20 para un programa que va a estar 10 años en cloud consumiendo cpu, dime donde está el ahorro.

Ahora, que si, que el programador se siente superbien porque ha hecho nosequé superápido.

[#19 FooDev]

#18 Eso suponiendo que se va a hacer un uso intensivo de dicho programa y que además el programa hace un uso intensivo de los recursos del sistema. Muchas veces no es así. A veces se trata de una simple web donde para más inri el cuello de botella de lo pone la BBDD (programada en C posiblemente).

[#20 Desactivado]

#19 Un servidor web, como el del meneo, está funcionando las 24 horas.

[#21 Desactivado]

#5 Estoy mirando el what's new in Python 3.11 y no veo que haya grandes cambios que joroben la compatibilidad. Nada diferente a lo que encuentras entre versiones que distan 3 o 4 releases. Y puedes tener 3.8 y 3.11 instalados a la vez (aún tengo python 2...).

[#22 wai]

#19 Que va, sin suponer uso intensivo. Como si se ejecuta una vez al día. El tiempo coste de cpu en 10 años no merece la pena.

Además, que estás suponiendo que el coste de cpu va a ser bajo forever

[#23 FooDev]

#20 Pero todo depende del uso que se le dé. Te aseguro que mis páginas web escritas en cualquier lenguaje interpretado funcionan perfectamente en mi Raspberry.

[#24 Desactivado]

#23 Solo respondía a eso de "según el uso que se le dé". 24 horas de uso diario hacen que cualquier ahorro sea interesante.

[#25 Desactivado]

Las implicaciones energéticas serían enormes si Python se usara directamente en tareas intensivas en CPU, para las cuales nadie elegiría Python.

(Y antes de que me digáis "pues python se usa para inteligencia artificial", responderé que sí, pero el "backend" de todas esas librerías es C/C++).

[#26 llorencs]

#5 #21 Cualquier cosa escrita en Python 3 funciona en las versiones posteriores. Por lo tanto no hay nada de compatibilidad rota, como bien dices. Pero eso sí, hay cosas nuevas en las revisiones que sí que pueden hacer que no funcionen si se ejecutan en Python anteriores. El caso más relevante en Python 3.10 sería el "match", que no existe en versiones anteriores.

[#27 Desactivado]

#26 Y para esos casos (aplicaciones en python que usen match) instalas el python de la versión que lo soporte. Por eso tengo 2 y 3 en mi sistema.

[#28 pawer13]

#7 EEE?

[#29 FooDev]

#24 A ver, no. No. Qué esté corriendo y accesible no implica que se le esté dando uso. Un aplicación web idle escrita en Python (que corre sobre un servidor escrito en C) te consume prácticamente lo mismo que una escrita en C.

[#30 tztxz0]

#25 En ciencia se usa mucho python para tareas intensivas en CPU. 

[#31 Nostradameus]

#28 Embrace, Extend, Extinguish

[#32 Desactivado]

#16 Los dos.

Se utiliza el término en inglés porque es una posición dentro de un equipo o empresa que se inventó en algún país de habla inglesa.

La documentación y los libros que se escribe sobre ello generalmente también es en inglés, por lo que traducirlo al español haría que la gente no se entendiera entre ella.

[#33 JoseElTenazas]

#18 ya llegó el típico programador meneante.

* Despliegan en producción 1 vez cada 10 años (deploy early and often? )
* De lo anterior se intuye que nunca aplican actualizaciones de software, ni siquiera las de seguridad.
* Escribir bugs y desplegar parches para los mismos es de débiles.
* Si código es escrito directamente en binario.
* Lo más cerca que han estado de cualquier lenguaje de alto nivel, son los artículos de magnet.xataka.com y genbeta.

Y así nos va. Vaya nivel...

[#34 Desactivado]

#8 Como apunta #17 , los lenguajes compilados son muchísimo más rápidos y consumen bastante menos recursos que los no compilados.

[#35 Desactivado]

#25 (Y antes de que me digáis "pues python se usa para inteligencia artificial", responderé que sí, pero el "backend" de todas esas librerías es C/C++).

Por curiosidad, ¿puedes explicar esto? Gracias

[#36 convidat78]

#35 pues básicamente, cuando usas las bibliotecas numpy/scipy ... en Python para realizar cálculos (o usas MATLAB), muchas veces estas bibliotecas hacen uso de, por ejemplo, las bibliotecas BLAS, lapack, ... vectorización, ... y de hecho en el anuncio de las optimizaciones de la versión 3.11 ya dicen que si tus programas hacen cálculos con numpy no habrá ninguna mejora.

[#37 abnog]

#14 #17 #34

Punto uno: no me jodáis la coña
Y punto dos: Java usa una máquina virtual al igual que Python, no es compilado.

[#38 Desactivado]

#35 claro.

Una característica de Python es su capacidad de invocar código que está escrito en C. Eso es algo que también tienen Java, Rust, Go...

Cuando tú programas en Python e invocas una biblioteca intensiva en cálculo, por ejemplo Tensorflow para redes neuronales o Numpy para cálculo numérico, estas bibliotecas proveen una interfaz en Python para que puedas programar con ellas en Python, pero el núcleo (lo que hace los cálculos) está escrito en C/C++. De esta manera, por una parte ganas la comodidad de programar en Python (si es que te gusta ese tipo de lenguajes) y por otra parte consigues un uso eficiente de tus recursos y una velocidad de ejecución aceptable.

Por ejemplo, código NumPy que está escrito en C++: https://github.com/numpy/numpy/blob/main/numpy/core/src/npymath/ieee754.cpp
O código del núcleo de Tensorflow, también escrito en C++: https://github.com/tensorflow/tensorflow/blob/master/tensorflow/core/ops/batch_ops.cc

C.c #30

[#39 llorencs]

#33 No hace falta ser borde.

[#40 exeware]

#13 40 veces más rapido mis coj...

[#41 lobomad]

#14 Y JavaScript, además no recarga el servidor ya que la carga del proceso se realiza en cliente.

El duelo final es entre Python y JavaScript

[#42 amchacon]

#18 que el desarrollo supone un pequeño porcentaje...? O no eres programador o tu experiencia en el mundo laboral es nulo.

Los proyectos nunca se acaban. Siempre hay errores o nuevas funcionalidades que aparecen.

Y sí, generalmente es más barato echar más hardware al problema que pagar más programadores. Que igualmente no es cierto porque la diferencia real de programar una aplicación web en Python o en C++ es nula.

[#43 amchacon]

#20 aparte de lo que te dicen. Ten en cuenta que no hay un único servidor web sino varios.

[#44 Desactivado]

#38 #36 Gracias.

[#45 amchacon]

#39 no es ser borde, es ser directo.

A mí lo que me sorprende esque #_18 tenga tantos votos positivos teniendo en cuenta que no tiene ni idea de desarrollo software.

[#46 amchacon]

#27 todavía hay aplicaciones que usen Python 2?

[#47 BloodStar]

Esto indica que antes el rendimiento era vergonzoso.

Cosa que por otro lado todos ya sabíamos.

[#48 Heni]

#c-15" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3762231/order/15">#15 No te quito la razón pero desde hace años tanto Java como C# (no sé python) en la primera ejecución de cada parte del código se compila el código intermedio (bytecode o Msil) a código máquina (mediante el just-in-time compiler) y la segunda vez que ejecuta esa parte del código se usa directamente el código compilado en lugar del código intermedio por lo que te rinde igual(o muy parecido) que lenguajes compilados directamente.

Optimizaciones que fueron saliendo con el tiempo

[#49 paco_camps_2011]

#4 ¿Y consume más o menos que Bitcooin?

[#50 Desactivado]

#19 Pues yo no suelo ver que el problema sea el rendimiento de las bases de datos, en la mayoría de aplicaciones comerciales que monitorizo y llevo como 15 clientes.

[#51 ostiayajoder]

#41 Javascript, como python, por ser interpretados, son MUCHISIMO mas consumidores de energia que java.

Y, de hecho, java consume mucho menos que .net (del orden de la mitad, ojo!).

Habia unas graficas por ahi que vi en internet hace uno o dos meses y, de las cuales, me llamo MUCHO la atencion eso: que java consumia poquisima energia (y sin graalVM ni nada)

[#52 Desactivado]

#45 A mi no me parece mal lo que dice. Muchas veces por meter prisa a los desarrolladores se cometen errores que luego tiran para atrás una versión. A veces es absurdo tanta prisa y sale más caro.

[#53 exeware]

#49 deepeendee

[#54 paco_camps_2011]

#37 #14 #17 #34 Que yo recuerde Java es compilado e interpretado, un punto intermedio.

[#55 Desactivado]

#42 Creo que se refiere al desarrollo inicial. Pero como dices nunca se termina de verdad de desarrollar una aplicación cuando es compleja, de hecho hoy en día desarrollo, producción y monitorización están muy integrados por esto. Amen de Seguridad, que cada X tiempo y con algunas aplicaciones como Dynatrace en tiempo real, te están reportando vulnerabilidades de seguridad que se deben corregir. Bueno en algunos sitios si es crítica o alta en 15 días o te apagan la aplicación

un saludo.

[#56 exeware]

#15 por supuesto, esa es la clave que es interpretado

[#57 Desactivado]

#47 Si pero python es fácil, para desarrolletes de administrar cosas te vale, te toma poco tiempo y hace su función. A mi me gusta, lo uso para atacar las apis de mi herramienta y hacer informes. También te digo, no soy un experto que me lei un libro de aprende python en un fide y tire "pa lante", pero claro para esas mierdecillas de programas me vale.

[#58 Wajahpantat]

#12 te tocarás los huevos a dos manos, no?

[#59 RubiaDereBote]

#18 " El desarrollo solo es un pequeño % en el tiempo de vida de un programa."

Debo confesar que se me has sacado una carcajada. El desarrollo de cualquier software es como un cáncer que se extiende durante toda su vida.

#13 ahora bien, así como le digo eso al compañero eso, a ti te digo que en Python hay cosas que se pueden programar muy rápidamente pero también es verdad que por la idiosincrasia del ecosistema Python, donde no se usa el tipado correspondiente ni de casualidad, hace que cualquier error sea una odisea encontrarlo y corregirlo. Eso hace que el tiempo que ahorras por un lado, lo pierdas por el otro con creces. Para mí, los únicos lenguajes que deberían usarse para aplicaciones que van a estar en producción, son aquellos que poseen un fuerte y estático tipado, y que además es obligatorio su uso. Eso es lo que más tiempo ahorra a un programador.
Python está muy bien para prototipado.

[#60 Aokromes]

#5 python3 --version
Python 3.9.2
debian stable.

[#61 ninefingers]

Volvamos a las CGIs en C.

[#62 Desactivado]

#18 si eso fuese cierto, no existiría PHP, y todas las empresas programarían todas sus webs directamente en C.

[#63 boikot]

#58 va a dias , pa que nos vamos a engañar

[#64 FooDev]

#50 Depende del tipo de aplicación pero, por lo general, en las aplicaciones web con las típicas acciones CRUD el cuello de botella está en las BBDD siempre. Gestionar una petición HTTP y que el controlador devuelva una respuesta es una acción casi instantánea, ya se trate de Python, PHP, Java o C. Repito, para aplicaciones con poca concurrencia.

[#65 Desactivado]

#38 Exactamente, y precisamente es eso lo que lo hace tan interesante: sintaxis sencilla, montón de librerías, y sin apenas pérdida de rendimiento, ya que el backend va en lenguajes de más bajo nivel.

Muy recomendable la librería Numba para ciertos cálculos científicos, sobre todo cuando se tengan que hacer muchas veces.

[#66 AlvaroLab]

#4 Si conoces Python y conoces C, supongo que también sabes son lenguajes muy distintos. Creo que es un poco injusto compararlos.

Vamos a comparar con Ruby, con PHP... no sé.

[#67 Desactivado]

#57 Y sencillamente hay muchas cosas en las que el rendimiento no importa. Me da igual que un programilla que voy a tener que correr 5 veces en mi vida tarde 2 segundos en vez de 10 ms, el tiempo de respuesta efectivo es el mismo, y la mayor facilidad a la hora de programar es notable.

[#68 tztxz0]

#38 Sí, pero es que no siempre se usan bien las invocaciones a librerías.

[#69 AlvaroLab]

#11

De el siguiente artículo - https://zathiro.wordpress.com/2010/08/21/python-lenguaje-semi-interpretado/
"Python tiene, no obstante, muchas de las características de los lenguajes compilados, por lo que se podría decir que es semi interpretado. En Python, como en Java y muchos otros lenguajes, el código fuente se traduce a un pseudo código máquina intermedio llamado bytecode la primera vez que se ejecuta, generando archivos .pyc o .pyo (bytecode optimizado), que son los que se ejecutarán en sucesivas ocasiones."

Supongo que se refiere a eso. No es una compilación al estilo C, pero sí hay un compilador.

[#70 JosemiGT]

#51

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharp.html

[#71 ppma]

#25 #65 #68
Bibliotecas

[#72 AlvaroLab]

#14 #37 #41 #17 Por favor, que alguien habra una batalla de ¿Cuál es el mejor lenguaje de programación? en Menéame. Las batallas políticas de estos foros van a quedar a la altura del betún.

[#73 unomasdelmonton]

#35 echa un ojo también a #38, que también habla del tema.

[#74 Desactivado]

#72 el mejor lenguaje de programación? Pues es que eso es como cuando tienes muchos hijos, quién es el mejor? El deportista polovalente , el que hace todo sencillo y fácil, el fuertote del gym, el que todo lo hace bien pero no destaca en nada, el que es tan rápido pero se choca porque no controla en la pista, el que nació viejo ...etc jajaja

[#75 Rexor]

#69 como haber hay módulos de compilación, tengo amigos que los usan, la verdad no los he usado nunca, sólo hago scripts para pentesting. Pero siempre me ha sonado que decir voy a compilar python es como decir voy a compilar php por ejemplo. Por eso hay lenguajes compilados y lenguajes interpretados, la arquitectura es completamente distinta.

[#76 hablador_pasivo]

#24 24 horas al día a 1 request por minuto es nada. No ahorras nada aunque lo hagas 100 veces más rápido.

[#77 amchacon]

#52 pero eso no tiene nada que ver con lo que ha dicho...

[#78 AlvaroLab]

#74 ya lo sé. Por eso encuentro divertido cuando forofos de distintos lenguajes se enzarzan. 😂 😂

[#79 Desactivado]

#76 No sé cómo habrán podido medir el 25% de nada.

[#80 AlvaroLab]

#75 creo que puedes compilar Python si quieres, para optimizar la "compilación" más (yo nunca lo he hecho).

Pero en general, la "compilación" de Python sucede de forma automática, que no quiere decir que no haya un compilador.

[#81 llorencs]

#64 Con bastante concurrencia Python tiene bibliotecas asíncronas que hacen que pueda ejecutarse con bastante rendimiento. Por ejemplo FastAPI es un buen servidor web asíncrono en Python.

[#82 exeware]

#66 conozco ambos, si tu tb los conoces sabrás que son comparables, que uno salga perdiendo no hace la comparación injusta. Hay casos de uso que ambos están muy distantes y otros que son muy similares por ejemplo el esp32 (chip iot) se programaria en C y python no parece pintar nada aqui pero resulta que este chip y otros muchos pueden usar un subset de python.
Pero vamos que la comparación no es idea mía, esta en el artículo donde se comparan unos 20 lenguajes. Además que la comparación se basa en una métrica bien concreta consumo de cpu.
Personalmente por experiencia se que la decisión de que lenguaje usar es algo que obedece a muchos factores, y muchas veces el rendimiento del lenguaje está al final de la lista. Por ejemplo si tu empresa solo hay programadores x, y legacy en x buscarán programarlo en x y si en algún momento cambian a y será por que no encuentran programadores x.

[#83 hablador_pasivo]

#79 eh?

[#84 RamonMercader]

#18 bienvenido a 2022. Ningún software comercial va a estar 10 años en la nube sin cambios.

La industria está transformándose hacia modelos de CI/CD para poder competir (eso en España, en otros sitios y en algunos sectores ya están 100% en ese modelo). El desarrollo es el mayor coste de cualquier producto de software, y con cosas como esta que reducen y optimizan el resto de costes, cada vez será un % mayor.

Y aun diría más, en cuanto las IAs que programen estén más afinadas y sirvan para un uso industrial, en lugar de reducir el número de programadores hará que se pase al siguiente nivel, donde desarrollos de años se hagan en meses y la demanda de software cada más complejo se dispare. Eso acabará haciendo que se necesiten incluso más programadores, ya que con una IA una pequeña empresa va a poder plantearse tener lonque ahora solo tienen las grandes empresas (y estas pasarán al siguiente escalón)

[#85 samuelCan]

Me gustaría comparar este ahorro con estacionar mi SUV 5 minutos con el motor en marcha.

[#86 Opinator_3.0]

He programado profesionalmente en más de 7 lenguajes, y puedo decir sin ningún género de dudas que Phyton es la mayor mierda que he visto y, para colmo, el que más éxito tiene (entre los que solo conocen ese lenguaje o no les gusta programar). Cuando lo empecé a estudiar, confieso que con cierta ilusión, no salía de mi asombro al constatar que este lenguaje había heredado lo peor de PHP, junto a lo peor de las tabulaciones, sintaxis horrorosa, con $ y _ por todos lados y encima dirás, ya que es feo, tendrá un rendimiento de cojones, pues tampoco. Es un lenguaje fallido para grandes proyectos pero supongo que para tirar cuatro líneas para automatizar algún proceso de sistemas valdrá. O también es usado por cojones, porque alguien tuvo la genial idea de desarrollar buenas librerías de IA en su día.

[#87 Desactivado]

#77 Bueno, yo lo entiendo como una critica a las prisas, pero es cierto que le echa la mierda al desarrollador como si pudiera elegir.

[#88 llorencs]

#86 Python usando $ por todos lados? Si no lo usa por ningún lado. Y decir que su sintaxis es fea...

Más fea es la sintaxis de Javascript o los derivados de C.

Las tabulaciones son malas? Hacen que el código sea mucho más legible. Dios, como odio programas que no tabulan los bloques y se hacen dificiles de saber donde empieza y termina un bloque. Con las tabulaciones ves visualmente e inmediatamente lo que corresponde a un bloque.

[#89 pawer13]

#18 El desarrollo inicial es el 20% del tiempo, el restante 80% del tiempo que un desarrollador va a estar leyendo y modificando ese código va a ser una vez que esté en producción: bug que se arreglan, modificaciones que se piden, nuevas funcionalidades... a menos que sea un código de usar y tirar, claro (campañas publicitarias, pruebas de concepto...).

[#90 AlvaroLab]

#82 Bajo mi punto de vista son difícilmente comparables, tanto en tipo de lenguaje como en sus aplicaciones.

[#91 pawer13]

#46 Lamentablemente sí, en mi empresa estamos migrando todavía a Python 3 algunas cosas. Y uno de los motivos es porque no puedes ya programar en Python 2 cómodamente en los nuevos Macs porque no hay builds para la arquitectura del M1.

[#92 pawer13]

#78 A mi me pone de los nervios presenciar esas discusiones, sobre todo porque todo el mundo defiende el lenguaje que a él le gusta/domina, porque no conoce el resto.

[#93 exeware]

#90 en uso de cpu/energía para un mismo uso son comparables 100%. Y otras muchas facetas tb, hay casos de usos que uno de los dos no aplica eso tb lo se.

[#94 Opinator_3.0]

#88 Efectivamente, el $ no es un símbolo básico de Python, lo he confundido con %, heredado de la sintaxis C, y que en mi opinión es horrible (hace unos tres años que empecé con Python y no lo he vuelto a tocar, afortunadamente).
Yo también soy un talibán de las tabulaciones pero eso no tiene nada que ver con que el sistema de llaves me parezca más cómodo y visual. Además las llaves permiten en lenguajes más modernos hacer closures , pasar comportamientos como argumento, etc que no creo que pudieran ser implementados sin llaves o algún otro símbolo que marque el inicio y fin de cada bloque. Al decir que no me gusta nada Python no quiero decir que JavaScript u otros lenguajes más veteranos sean más "bonitos", pero para ser Python un lenguaje relativamente reciente me parece bastante obsoleto estéticamente y encima con pobre rendimiento y limitaciones técnicas de despliegue. Si echas un vistazo a Swift o Kotlin, o incluso las últimas versiones de java, dices, joder qué cómodo e intuitivo todo.

[#95 SaulBadman]

#18 Ya, pero la realidad es que la mayoría de servidores corren código en JavaScript, Python, PHP, Java, y demás lenguajes que no son demasiado conocidos por son demasiados conocidos por si eficiencia.

Según tengo entendido, para encontrar C, C++, Rust, y similares en el backend de un servidor tiene que ser algo que maneje flujos de datos enormes, como puedan ser los servidores de YouTube, Netflix y demás

[#96 AlvaroLab]

#93 Es como comparar, un delantero y un portero. Claro que se pueden comparar... pero... bueno, eso.
Puedes comparar el número de penalties que un portero y un delantero paran, sí. Puedes comparar el número de goles que marcan, sí.

Puedes hacer desarrollo backend web con C, sí. Sería una locura, sí.
Puedes hacer programación de bajo nivel con Python, sí. Sería una locura, sí.

Python es mucho más accesible que C y eso lo hace más lento que C. El cometido de los 2 es muy distinto.

Luego ya... compilado vs interpretado, tipado dinámico vs estático...

[#97 AlvaroLab]

#92 Y porque se comparan churras con merinas... como se compara un Java para Android, con un Python para backend, con un Javascript para frontend...

[#98 llorencs]

#94 Java no me entra. No lo trago. No hay manera.

En Python puedes hacer "closures" sin ningún problema. Son bastante habituales. Por ejemplo todos los decoradores vendrían de un "closure".

En strings modernos, lo del % no lo usas para nada. Yo nunca he necesitado esa sintaxis. Escribes algo así: f'mi nombre es: ' Y tira millas.

[#99 Opinator_3.0]

#98 ¿Con números tampoco necesitas %?

[#100 Malandrico]

En este podcast sale Guido hablando del tema: