PEP 8, ¿por qué no hay espacios alrededor de '=' en un argumento de palabra clave o un valor de parámetro predeterminado?

103

¿Por qué PEP 8 recomienda no tener espacios =en un argumento de palabra clave o un valor de parámetro predeterminado ?

¿Es esto inconsistente con la recomendación de espacios alrededor de cualquier otra aparición de =en el código Python?

Como es:

func(1, 2, very_long_variable_name=another_very_long_variable_name)

mejor que:

func(1, 2, very_long_variable_name = another_very_long_variable_name)

Se agradecerá cualquier enlace a la discusión / explicación del BDFL de Python .

Tenga en cuenta que esta pregunta se trata más de kwargs que de valores predeterminados, acabo de usar la fraseología de PEP 8.

No estoy solicitando opiniones. Estoy preguntando las razones detrás de esta decisión. Es más como preguntar por qué lo usaría {en la misma línea que una ifdeclaración en un programa C, no si debería usarlo o no.

python coding-style pep8

— control de alma
fuente

72

Supongo que se debe a que un argumento de palabra clave es esencialmente diferente a una asignación de variable.

Por ejemplo, hay mucho código como este:

kw1 = some_value
kw2 = some_value
kw3 = some_value
some_func(
    1,
    2,
    kw1=kw1,
    kw2=kw2,
    kw3=kw3)

Como puede ver, tiene mucho sentido asignar una variable a un argumento de palabra clave con el mismo nombre, por lo que mejora la legibilidad para verlos sin espacios. Es más fácil reconocer que estamos usando argumentos de palabras clave y no asignándonos una variable a sí mismo.

Además, los parámetros tienden a ir en la misma línea, mientras que las asignaciones suelen estar cada una en su propia línea, por lo que es probable que ahorrar espacio sea un asunto importante allí.

— fortran
fuente

6

este podría ser el caso, pero todavía parece extraño introducir esta coherencia de iconos de la OMI en las recomendaciones de estilo de código para un lenguaje tan bien diseñado, solo para guardar 2 caracteres. Es como si el estilo del código Java dijera que es mejor poner {una nueva línea después if(guarda el mismo número de caracteres) pero no en la definición de clase. Además, un parámetro de palabra clave es diferente al valor predeterminado, pero sigue utilizando la misma recomendación de estilo.

— Soulcheck

3

Como dije, son cosas diferentes. Tiene sentido escribirlos de manera diferente.

— fortran

6

Yo diría que no es más legible que kw1 = kw1, kw2 = kw2;) pero tal vez eso fue lo que pensaron Guido y Barry.

— soulcheck

1

Aceptaré esta respuesta porque es bastante convincente. Sin embargo, no me importaría un enlace que lo confirme

— soulcheck

5

El hecho de que el argumento de la palabra clave sea fundamentalmente diferente de la asignación de variables no es un argumento válido para tener diferentes convenciones, en mi opinión, porque la diferencia ya es clara en el contexto. El primero ocurre dentro de una llamada de función y el segundo debe estar solo en el nivel de sangría actual. En mi opinión, para nombres de variables de más de 5-6 caracteres (es decir, la vida real para la mayoría), la variante con espacios es más legible.

— Axel

13

No usaría very_long_variable_name como argumento predeterminado. Así que considera esto:

func(1, 2, axis='x', angle=90, size=450, name='foo bar')

Más allá de esto:

func(1, 2, axis = 'x', angle = 90, size = 450, name = 'foo bar')

Además, no tiene mucho sentido utilizar variables como valores predeterminados. Quizás algunas variables constantes (que en realidad no son constantes) y, en ese caso, usaría nombres en mayúsculas, descriptivos pero lo más cortos posible. Así que no otro_muy_...

— rplnt
fuente

1

esos son argumentos de palabras clave, un ejemplo similar está en PEP solo lo hice menos legible

— soulcheck

3

Estás diciendo (esencialmente): para hacer que la regla sin espacio sea sensata, escribe nombres de variable muy cortos. Pero SI uno tiene nombres de variable largos, entonces la regla sin espacio crea un entorno desordenado. El argumento de que 'no es una asignación, entonces son cosas diferentes' no me sirve, porque me importa más la legibilidad que la semántica y porque si no es un 'valor predeterminado para una asignación', entonces ¿qué es? ¿eso?

— PatrickT

1

@PatrickT El argumento "no es una tarea, entonces son cosas diferentes" no explica por qué lo es (una noción filosófica); Simplemente explica por qué puede ser (una noción sintáctica).

— Mateen Ulhaq

11

Hay pros y contras.

Me disgusta mucho cómo se lee el código compatible con PEP8. No creo en el argumento que very_long_variable_name=another_very_long_variable_namejamás puede ser más legible por humanos que very_long_variable_name = another_very_long_variable_name. No es así como lee la gente. Es una carga cognitiva adicional, particularmente en ausencia de resaltado de sintaxis.

Sin embargo, hay un beneficio significativo. Si se cumplen las reglas de espaciado, la búsqueda de parámetros utilizando exclusivamente herramientas es mucho más efectiva.

— Thomas Hywel
fuente

Bueno, si se adhiere a poner espacios alrededor =, la búsqueda con herramientas no debería ser diferente.

— NoName

10

En mi opinión, omitir los espacios para los argumentos proporciona una agrupación visual más limpia de los pares arg / valor; parece menos desordenado.

— JoeC
fuente

En general, me gustan los espacios, tanto que tiendo a poner espacios dentro de los paréntesis también para que todos los parámetros estén rodeados por espacio. Pero creo que arg1=40es más legible ya que la relación es más obvia.

— Charlie Gorichanaz

3

Creo que hay varias razones para esto, aunque podría estar racionalizando:

Ahorra espacio, permitiendo que más definiciones de funciones y llamadas quepan en una línea y ahorrando más espacio para los nombres de los argumentos.
Al unir cada palabra clave y valor, puede separar más fácilmente los diferentes argumentos por el espacio después de la coma. Esto significa que puede observar rápidamente cuántos argumentos ha proporcionado.
Entonces, la sintaxis es distinta de las asignaciones de variables, que pueden tener el mismo nombre.
Además, la sintaxis es (incluso más) distinta de las comprobaciones de igualdad a == bque también pueden ser expresiones válidas dentro de una llamada.

— otus
fuente

3

Para mí, hace que el código sea más legible y, por lo tanto, es una buena convención.

Creo que la diferencia clave en términos de estilo entre las asignaciones de variables y las asignaciones de palabras clave de función es que solo debería haber una única =en una línea para las primeras, mientras que generalmente hay múltiples =s en una línea para las últimas.

Si no hubiera otras consideraciones, preferiríamos foo = 42hacerlo foo=42, porque el segundo no es el formato típico de los signos iguales y porque el primero separa visualmente la variable y el valor con espacios en blanco.

Pero cuando hay varias asignaciones en una línea, preferimos f(foo=42, bar=43, baz=44)hacerlo f(foo = 42, bar = 43, baz = 44), porque la primera separa visualmente las diversas asignaciones con espacios en blanco, mientras que la segunda no lo hace, lo que hace que sea un poco más difícil ver dónde están los pares de palabra clave / valor.

Aquí hay otra manera de decirlo: no es una consistencia detrás de la convención. Esa consistencia es la siguiente: el "nivel más alto de separación" se hace visualmente más claro a través de los espacios. Los niveles inferiores de separación no lo son (porque se confundiría con el espacio en blanco que separa el nivel superior). Para la asignación de variables, el nivel más alto de separación es entre variable y valor. Para la asignación de palabras clave de función, el nivel más alto de separación es entre las asignaciones individuales en sí.

— Denziloe
fuente