Las muchas formas de formateo de cadenas de Python: ¿están las más antiguas (van a ser) desaprobadas?

Python tiene al menos seis formas de formatear una cadena:

In [1]: world = "Earth" # method 1a In [2]: "Hello, %s" % world Out[2]: 'Hello, Earth' # method 1b In [3]: "Hello, %(planet)s" % {"planet": world} Out[3]: 'Hello, Earth' # method 2a In [4]: "Hello, {0}".format(world) Out[4]: 'Hello, Earth' # method 2b In [5]: "Hello, {planet}".format(planet=world) Out[5]: 'Hello, Earth' # method 2c In [6]: f"Hello, {world}" Out[6]: 'Hello, Earth' In [7]: from string import Template # method 3 In [8]: Template("Hello, $planet").substitute(planet=world) Out[8]: 'Hello, Earth' 

Una breve historia de los diferentes métodos:

  • printf formato de estilo printf ha existido desde la infancia de Pythons
  • La clase de Template se introdujo en Python 2.4
  • El método de format fue introducido en Python 2.6
  • f cuerdas se introdujeron en Python 3.6

Mis preguntas son:

  • ¿El formato del estilo printf está en desuso o va a ser desaprobado?
  • En la Template class , ¿el método substitute desuso o se va a desaprobar? (No estoy hablando de safe_substitute , que, según tengo entendido, ofrece capacidades únicas)

Preguntas similares y por qué creo que no son duplicados:

  • Formato de cadena de Python:% vs. .format : trata solo los métodos 1 y 2, y pregunta cuál es mejor; Mi pregunta es explícitamente sobre la desaprobación a la luz del Zen de Python.

    • Opciones de formato de cadena: ventajas y desventajas : trata solo los métodos 1a y 1b en la pregunta, 1 y 2 en la respuesta, y también nada sobre la desaprobación

    • Formateo avanzado de cadenas vs cadenas de plantillas , principalmente sobre los métodos 1 y 3, y no aborda la desaprobación

    • Expresiones de formato de cadena (Python) : la respuesta menciona que el enfoque ‘%’ original está previsto que esté en desuso . Pero, ¿cuál es la diferencia entre lo que se planea en desuso , el depreciación pendiente y el depreciación real? Y el método de estilo printf no PendingDeprecationWarning siquiera una PendingDeprecationWarning , ¿entonces esto realmente va a ser desaprobado? Esta publicación también es bastante antigua, por lo que la información puede estar desactualizada.

    Ver también

    • PEP 502: Interpolación de cadenas – Discusión extendida
    • Formateador de cuerdas

    Si bien hay varias indicaciones en los documentos de que .format y f-strings son superiores a % strings, no hay un plan sobreviviente que desapruebe a este último.

    En la edición de compromiso n . ° 14123: mencione explícitamente que el formato de cadena% de estilo antiguo tiene advertencias pero no desaparecerá en el corto plazo. , inspirado por el problema Indique que no hay planes actuales para desaprobar el formato de estilo printf , los documentos en formato % se editaron para contener esta frase:

    Como la nueva syntax de formato de cadena es más flexible y maneja tuplas y diccionarios de forma natural, se recomienda para el nuevo código. Sin embargo, no hay planes actuales para desaprobar el formato de estilo printf .

    (Énfasis mío.)

    Esta frase se eliminó más tarde, en commit Cerrar # 4966: renovar la secuencia de documentos para explicar mejor el estado de Python moderno . Esto puede parecer una señal de que un plan para desaprobar el formato de % volvió a aparecer en las tarjetas … pero al bucear en el rastreador de errores se revela que la intención era la contraria. En el rastreador de errores, el autor de la confirmación caracteriza el cambio de la siguiente manera :

    • cambió la prosa que describe la relación entre el formato de estilo printf y el método str.format (eliminando deliberadamente la implicación de que el primero es un peligro real de desaparecer; simplemente no es práctico para nosotros contemplar seriamente matarlo)

    En otras palabras, hemos tenido dos cambios consecutivos en los documentos con formato % pretenden enfatizar explícitamente que no será obsoleto, y mucho menos eliminado. Los documentos siguen opinando sobre los méritos relativos de los diferentes tipos de formato de cadena, pero también están claros que el formato % no va a quedar obsoleto o eliminado.

    Además, el cambio más reciente a ese párrafo , en marzo de 2017, lo cambió a partir de este …

    Las operaciones de formateo descritas aquí muestran una variedad de peculiaridades que conducen a una serie de errores comunes (como no mostrar las tuplas y los diccionarios correctamente). El uso de los nuevos literales de cadena con formato o la interfaz str.format ayuda a evitar estos errores. Estas alternativas también proporcionan enfoques más potentes, flexibles y extensibles para dar formato al texto.

    … a esto:

    Las operaciones de formateo descritas aquí muestran una variedad de peculiaridades que conducen a una serie de errores comunes (como no mostrar las tuplas y los diccionarios correctamente). El uso de los nuevos literales de cadena con formato, la interfaz str.format o las cadenas de plantilla pueden ayudar a evitar estos errores. Cada una de estas alternativas ofrece sus propias ventajas y desventajas y beneficios de simplicidad, flexibilidad y / o extensibilidad.

    Observe que el cambio de “ayuda a evitar” a “puede ayudar a evitar”, y cómo la clara recomendación de .format y f-strings ha sido reemplazada por una prosa mullida y equívoca acerca de cómo cada estilo “ofrece sus propias ventajas y desventajas” . Es decir, no solo ya no hay una desaprobación formal en las tarjetas, sino que los documentos actuales reconocen abiertamente que el % formato al menos tiene algunos “beneficios” sobre los otros enfoques.

    De todo esto inferiría que el movimiento para desaprobar o eliminar el formato % no solo ha fallado, sino que ha sido derrotado completamente y permanentemente.

    El nuevo método .format() está destinado a reemplazar la antigua syntax de formato % . Este último ha sido desestimado (pero aún no oficialmente desaprobado). La documentación del método establece lo siguiente:

    Este método de formato de cadena es el nuevo estándar en Python 3, y debería preferirse al formato de % descrito en Operaciones de formato de cadena en el nuevo código.

    (Énfasis mío).

    Para mantener la compatibilidad con versiones anteriores y para facilitar la transición, el formato antiguo se ha dejado en su lugar por ahora . De la propuesta original PEP 3101 :

    Compatibilidad al revés

    La compatibilidad con versiones anteriores se puede mantener dejando los mecanismos existentes en su lugar. El nuevo sistema no choca con ninguno de los nombres de métodos de las técnicas de formato de cadena existentes, por lo que ambos sistemas pueden coexistir hasta que llegue el momento de dejar de usar el sistema anterior.

    Tenga en cuenta hasta que llegue el momento de desaprobar el sistema anterior ; no ha quedado en desuso, pero el nuevo sistema se utilizará cada vez que escriba un nuevo código .

    El nuevo sistema tiene como ventaja que puede combinar el enfoque de tupla y diccionario del antiguo formateador % :

     "{greeting}, {0}".format(world, greeting='Hello') 

    y es extensible a través del object.__format__() hook usado para manejar el formato de valores individuales.

    Tenga en cuenta que el sistema anterior tenía % y la clase de Template , donde esta última le permite crear subclases que agregan o alteran su comportamiento. El sistema de nuevo estilo tiene la clase Formatter para llenar el mismo nicho.

    Python 3 se ha alejado aún más de la desaprobación, en lugar de eso, te advierte en la sección Formato de printf estilo printf :

    Nota : Las operaciones de formato que se describen aquí muestran una variedad de peculiaridades que conducen a una serie de errores comunes (como no mostrar las tuplas y los diccionarios correctamente). El uso de los nuevos literales de cadena con formato o la interfaz str.format() ayuda a evitar estos errores. Estas alternativas también proporcionan enfoques más potentes, flexibles y extensibles para dar formato al texto.

    Python 3.6 también agregó literales de cadena con formato , que alinean las expresiones en las cadenas de formato. Estos son el método más rápido para crear cadenas con valores interpolados, y se deben usar en lugar de str.format() siempre que pueda usar un literal.

    El operador % para el formato de cadena no está en desuso y no se eliminará, a pesar de las otras respuestas.
    Cada vez que el tema se plantea en la lista de desarrollo de Python, existe una gran controversia sobre cuál es mejor, pero no hay controversia sobre si eliminar el método clásico: se mantendrá. A pesar de estar indicado en PEP 3101, Python 3.1 había llegado y se había ido, y el formato % todavía existe.

    Las declaraciones para mantener el estilo clásico son claras: es simple, es rápido, es rápido para hacer cosas cortas. El uso del método .format no siempre es más legible, y casi nadie, incluso entre los desarrolladores centrales, puede usar la syntax completa proporcionada por .format sin tener que consultar la referencia Incluso en 2009, uno tenía mensajes como este: http: //mail.python.org/pipermail/python-dev/2009-Octubre/092529.html – el tema apenas había aparecido en las listas desde entonces.

    Actualización 2016

    En la versión de desarrollo actual de Python (que se convertirá en Python 3.6) hay un tercer método de interpolación de cadenas, descrito en PEP-0498 . Define un nuevo prefijo de cita f"" (además de la u"" , b"" r"" actuales).

    El prefijo de una cadena por f llamará a un método en el objeto de cadena en tiempo de ejecución, que interpolará automáticamente las variables del scope actual en la cadena:

     >>> value = 80 >>> f'The value is {value}.' 'The value is 80.' 

    La última posición de Guido sobre esto parece estar indicada aquí:

    Novedades en Python 3.0

    PEP 3101: un nuevo enfoque para el formato de cadenas

    Un nuevo sistema para las operaciones de formato de cadena incorporadas reemplaza al operador de formato de cadena%. (Sin embargo, el operador% aún es compatible; se desaprobará en Python 3.1 y se eliminará del idioma en algún momento posterior). Lea el PEP 3101 para obtener la información completa.

    Y el PEP3101 en sí, que tiene la última modificación que se remonta a (viernes, 30 de septiembre de 2011), por lo que no hay avances últimamente, supongo.

    Mirando los documentos antiguos de Python y PEP 3101, hubo una statement de que el operador% quedará en desuso y será eliminado del idioma en el futuro. La siguiente statement estaba en los documentos de Python para Python 3.0, 3.1 y 3.2:

    Dado que str.format () es bastante nuevo, una gran cantidad de código Python todavía usa el operador%. Sin embargo, debido a que este antiguo estilo de formato finalmente se eliminará del lenguaje, generalmente se debe usar str.format ().

    Si va a la misma sección en los documentos de Python 3.3 y 3.4, verá que esa statement ha sido eliminada. Tampoco puedo encontrar ninguna otra statement en ningún otro lugar en la documentación que indique que el operador quedará en desuso o será eliminado del idioma. También es importante tener en cuenta que PEP3101 no se ha modificado en más de dos años y medio (viernes, 30 de septiembre de 2011).

    Actualizar

    PEP461 Se acepta agregar% de formato a bytes y bytearray y debe ser parte de Python 3.5 o 3.6. Es otra señal de que el operador% está vivo y pateando.