PEP 8, pourquoi n'y a-t-il pas d'espaces autour de "=" dans un argument de mot-clé ou une valeur de paramètre par défaut ?

Question

Pourquoi les PEP 8 recommande de ne pas mettre d'espaces autour des = dans un argument de mot-clé ou une valeur de paramètre par défaut ?

Cela est-il incompatible avec le fait de recommander l'insertion d'espaces autour d'une occurrence sur deux de = dans le code Python ?

Comment est :

func(1, 2, very_long_variable_name=another_very_long_variable_name)

mieux que :

func(1, 2, very_long_variable_name = another_very_long_variable_name)

Existe-t-il des liens vers des discussions/explications de Python ? BDFL seront appréciés.

Attention, cette question concerne davantage les kwargs que les valeurs par défaut, j'ai simplement utilisé la formulation du PEP 8.

Je ne sollicite pas d'avis. Je demande les raisons de cette décision. Il s'agit plutôt de demander pourquoi utiliserais-je { sur la même ligne que if dans un programme C, et non si Je dois l'utiliser ou non.

Answer 1

Je suppose que c'est parce qu'un argument de mot-clé est essentiellement différent d'une affectation de variable.

Par exemple, il y a beaucoup de code comme celui-ci :

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

Comme vous le voyez, il est tout à fait logique d'assigner une variable à un argument de mot-clé nommé exactement de la même manière, et il est donc plus facile de les voir sans espaces. Il est plus facile de reconnaître que nous utilisons des arguments de mots-clés et que nous n'assignons pas une variable à elle-même.

En outre, les paramètres ont tendance à être placés sur la même ligne, alors que les affectations sont généralement placées chacune sur leur propre ligne, de sorte que l'économie d'espace est probablement un élément important.

Answer 2

Il y a des avantages et des inconvénients.

Je n'aime pas du tout la façon dont le code conforme au PEP8 se lit. Je n'adhère pas à l'argument selon lequel very_long_variable_name=another_very_long_variable_name ne pourra jamais être plus lisible pour l'homme que very_long_variable_name = another_very_long_variable_name . Ce n'est pas ainsi que les gens lisent. C'est une charge cognitive supplémentaire, en particulier en l'absence de coloration syntaxique.

Il y a cependant un avantage important. Si les règles d'espacement sont respectées, la recherche des paramètres devient plus facile. l'utilisation d'outils beaucoup plus efficace.

Answer 3

Je n'utiliserais pas very_long_variable_name comme argument par défaut. Considérez donc ceci :

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

sur ce sujet :

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

En outre, il n'est pas très logique d'utiliser des variables comme valeurs par défaut. Peut-être quelques variables constantes (qui ne sont pas vraiment des constantes) et dans ce cas, j'utiliserais des noms en majuscules, descriptifs mais aussi courts que possible. Donc pas de another_very_...

Answer 4

L'absence d'espaces pour les args permet de regrouper visuellement les paires arg/valeur de manière plus propre, ce qui évite l'encombrement.

Answer 5

Pour moi, cela rend le code plus lisible et c'est donc une bonne convention.

Je pense que la principale différence en termes de style entre les affectations de variables et les affectations de mots clés de fonctions est qu'il ne doit y avoir qu'un seul = sur une ligne pour le premier, alors que généralement il y a plusieurs = sur une ligne pour ce dernier.

En l'absence d'autres considérations, nous préférerions foo = 42 à foo=42 parce que ce dernier n'est pas le format habituel des signes d'égalité et parce que le premier sépare visuellement la variable et la valeur par un espace blanc.

Mais lorsqu'il y a plusieurs affectations sur une même ligne, nous préférons f(foo=42, bar=43, baz=44) à f(foo = 42, bar = 43, baz = 44) parce que le premier sépare visuellement les différentes affectations par des espaces blancs, alors que le second ne le fait pas, ce qui rend un peu plus difficile de voir où se trouvent les paires mot-clé/valeur.

Voici une autre façon de présenter les choses : il y a es une cohérence derrière la convention. Cette cohérence est la suivante : le "plus haut niveau de séparation" est rendu visuellement plus clair par les espaces. Les niveaux de séparation inférieurs ne le sont pas (parce qu'ils seraient confondus avec l'espace blanc séparant le niveau supérieur). Pour l'affectation de variables, le niveau de séparation le plus élevé se situe entre la variable et la valeur. Pour l'affectation d'un mot-clé de fonction, le niveau de séparation le plus élevé se situe entre les affectations individuelles elles-mêmes.