Estoy usando .format() mucho en mis proyectos de Python 3.5, pero me temo que quedará obsoleto durante las próximas versiones de Python debido a las cadenas f, el nuevo tipo de literal de cadena.
>>> name = "Test" >>> f"My app name is {name}." 'My app name is Test.' ¿La función de cadena formateada viene a reemplazar completamente el antiguo .format() ? Y de ahora en adelante, ¿sería mejor usar el nuevo estilo en todos los casos?
Entiendo que se basa en la idea de que "lo simple es mejor que lo complejo". Sin embargo, ¿qué pasa con los problemas de rendimiento; ¿Hay alguna diferencia entre ellos? ¿O es solo un simple aspecto de la misma característica?
Me temo que quedará obsoleto durante las próximas versiones de Python.
No se preocupe, str.format no parece (ni tiene una razón) para irse pronto, el PEP que introdujo cadenas con prefijo f incluso afirma en su resumen :
Este PEP no propone eliminar ni desaprobar ninguno de los mecanismos de formato de cadena existentes.
Las cadenas formateadas se introdujeron para abordar algunas de las deficiencias que tenían otros métodos para formatear cadenas; no desechar los métodos antiguos y obligar a Dios sabe cuántos proyectos a usar f-string si quieren que su código funcione para Python 3.6+.
En cuanto al rendimiento de estos, parece que mi sospecha inicial de que podrían ser más lentos es incorrecta, las cadenas f parecen superar fácilmente a sus contrapartes .format .:
➜ cpython git:(master) ./python -m timeit -s "a = 'test'" "f'formatting a string {a}'" 500000 loops, best of 5: 628 nsec per loop ➜ cpython git:(master) ./python -m timeit "'formatting a string {a}'.format(a='test')" 100000 loops, best of 5: 2.03 usec per loopEstos se realizaron contra la rama maestra del repositorio de CPython a partir de este escrito; definitivamente están sujetos a cambios:
f-strings , como nueva característica, podría tener posibles optimizaciones.format sea más rápido (por ejemplo , el método Speedup llama a 1.2x )Pero realmente, no te preocupes tanto por la velocidad, preocúpate por lo que es más legible para ti y para los demás.
En muchos casos, será f-strings , pero hay algunos casos en los que el format es mejor.
Para desarrollar la respuesta de Jim y abordar su problema de rendimiento, utilicé el módulo dis de python para comparar las instrucciones del código de bytes para dos funciones sintácticamente diferentes, pero funcionalmente equivalentes.
import dis def f1(): a = "test" return f"{a}" def f2(): return "{a}".format(a='test') print(dis.dis(f1)) print(dis.dis(f2))cuyo resultado es:
11 0 LOAD_CONST 1 ('prueba')
2 ALMACENAR_RÁPIDO 0 (a)
12 4 CARGA_RÁPIDA 0 (a)
6 FORMATO_VALOR 0
8 RETURN_VALUE
Ninguna
15 0 LOAD_CONST 1 ('{a}')
2 LOAD_ATTR 0 (formato)
4 LOAD_CONST 2 ('prueba')
6 LOAD_CONST 3 (('a',))
8 CALL_FUNCTION_KW 1
10 RETURN_VALUE
Ninguna Se puede ver que f-string maneja el formateo sin atributos o llamadas a funciones, lo que puede imponer la verificación de tipos y la sobrecarga de memoria. Según timeit , esto da como resultado una ganancia de rendimiento de aproximadamente 3 veces (para mis funciones específicas)
>>> timeit.timeit('f1()', 'from __main__ import f1', number=100000)
0.012325852433775708
>>> timeit.timeit('f2()', 'from __main__ import f2', number=100000)
0.036395029920726074Una cosa que no se menciona, lo que hace imposible la desaprobación de las técnicas antiguas, es que la interpolación es solo para cadenas literales. Es decir, la cadena se procesa una vez en tiempo de ejecución y la plantilla no está disponible para usarse nuevamente con variables actualizadas. Como lo harías por ejemplo:
>>> str_template = '{i} squared: {n}' >>> for i in range(2, 5): ... print(str_template.format(i=i, n=i**2)) ... 2 squared: 4 3 squared: 9 4 squared: 16 Otro caso es i18n , donde se usa string.Template . Muchos casos de uso serían imposibles sin las técnicas más antiguas. Disfrute de la interpolación de cadenas, pero no está disponible para todos los casos de uso, es decir, lugares donde necesita una plantilla reutilizable.