¿Por qué el método de 'formato' no se usa más en Python?

8

Probablemente me falta algo aquí, después de buscar no pude encontrar una respuesta.

He explorado bastantes proyectos de Python y una cosa que sigo notando es el hecho de que la mayoría de ellos continúan usando el %operador para formatear cadenas en lugar del .format()método más nuevo y recomendado . ¿Hay alguna razón para esto? parece un cambio trivial, a menos que me falte algo por completo.

Por ejemplo:

# count how many times the % operator technique is used
find . -name "*.py" -exec grep -HE "\"[^\"]+\"\s\%\s\w+|'[^']+'\s\%\s\w+" {} \; | wc -l

# and the same for format()
find . -name "*.py" -exec grep -HE "\w+\.format\(" {} \; | wc -l

# Results:
#
#               % operator        format()
# iPython          670               63
# Django           977               8
# Tornado          91                0
# requests         25                1

No hay una razón real para esta pregunta, solo curiosidad.

¡Animo amigos!

python

— Mate
fuente

2

¿A la gente le gusta escribir menos y también tiene código escrito antes de que hubiera un .format()método?

— Wooble

FWIW, el viejo %es más eficiente y menos detallado para los reemplazos simples de cadenas. Lo uso la mayoría de las veces, y cuando necesito un formato más potente.format

— elijo el

16

Tres inclinaciones extremadamente fuertes se unen para producir este efecto:

Comodidad: "Sé cómo hacer esto a la antigua usanza, aprender la nueva forma sería un mayor esfuerzo".
compensación de esfuerzo / efecto: "¿Se ha ido el viejo método? ¿Está en desuso? ¿No? Entonces no hay ningún caso comercial para cambiar esto. Cree un nuevo código en su lugar".
Seguridad: "¿Está seguro de que la nueva forma propuesta de hacer las cosas es exactamente equivalente? ¿No? Entonces mejor deje el código antiguo como está, podría introducir defectos".

Los tres son, de hecho, bastante sensatos (el primero menos, ya que el aprendizaje continuo es en lo que los trabajadores de la información deberían prosperar).

( Editar: como se señala a continuación, hay un cuarto punto: ¡no saber que el nuevo método existe! Esto es menos sensato, pero en realidad podría ser el más común).

— Kilian Foth
fuente

44

+1 quizás hay 4. ignorancia de que incluso hay una nueva forma

— jk.

1

@jk. +1 no sabía que existía format ().

— Joe Z.

+1, pero incluye ese cuarto punto. Noto una y otra vez en SO que cada vez que muestro el .format()método o la format()función, las personas simplemente no saben que existen .

— Martijn Pieters

1

Añadiría que noformat es un equivalente de . Por ejemplo, usando puede usar para especificar el ancho mínimo del campo (por ejemplo, formatea el flotante con al menos dígitos), mientras que con no puede hacer esto. Y probablemente existan otras cosas que pueden hacer mientras que no. %%*'%.*f' % (7, 2.34)2.347formatformat%

— Bakuriu

3

Gran respuesta. Además, @Bakuri es posible format, aunque no es tan conciso - "{0:.{1}f}".format(2.34, 7). No he encontrado nada que %pueda hacer que formatno pueda.

— Matt

6

Además de las otras razones, agregaría compatibilidad y consistencia hacia atrás. A menudo necesita escribir scripts que puedan ejecutarse en las computadoras de otras personas, que no quieren o no pueden actualizarse a la última y mejor Python. Entonces escribes al mínimo común denominador. En el momento en que suficientes usuarios hayan actualizado a una versión suficientemente reciente de Python, probablemente haya olvidado qué características aparecieron en cada versión de Python. A menos que sean características excepcionalmente valiosas, puede que no valga la pena investigar, considerar y decidir si ahora es seguro usar cada función. El método de método de formato es una buena API para usar en código nuevo, pero el caso para introducirlo en una base de código que ya usa% extensivamente no es tan fuerte.

— Weeble
fuente

2

Al desarrollar software para su propio uso, a menudo le conviene utilizar versiones más nuevas de sus bibliotecas y herramientas de desarrollo. Sin embargo, los proyectos que está viendo son bibliotecas y herramientas de desarrollo destinadas a ser compartidas con la comunidad. En estos casos, desea ser conservador en las características que necesita para obtener la base instalada más amplia y lograr que la mayoría de las personas participen en el proyecto.

El format()método no se agregó hasta el lanzamiento de Python 3.0 / 2.6 en 2008. Parece que fue hace mucho tiempo, pero tenga en cuenta que las personas rara vez usan la primera versión del software. Pongamos esto en contexto cuando estuvo disponible en dos de las distribuciones de Linux más 'serias'. RHEL 5.x todavía usa Python 2.4 y es compatible hasta 2017 - 6.x tiene Python 2.6 pero eso no fue lanzado hasta 2010. En el campamento de Debian no tenían Python 2.6 hasta la serie 6.x que se estabilizó en 2011

Entonces, si bien puede tener sentido, si comenzaras un proyecto como Django (lanzado originalmente en 2005) hoy, para estandarizar el nuevo método, hay muy poco valor en retroceder y cambiar las 1000 ocurrencias del método anterior sin que tenga sido formalmente en desuso. Hace el trabajo, crea la posibilidad de introducir errores y aumenta innecesariamente los requisitos del sistema.

— Sean McSomething
fuente

0

Además de la respuesta de @ KilianFoth; portar un gran proyecto a una versión de software superior tiene mucho trabajo por hacer. Y cambiar un uso no obsoleto tiene la menor importancia en el proceso de actualización.

Probablemente estén usando un nuevo formato en partes totalmente reescritas y no cambien el uso existente en el resto.

— Ángel caido
fuente