web-dev-qa-db-fra.com

PEP 8, pourquoi aucun espace autour de '=' dans l'argument mot-clé ou une valeur de paramètre par défaut?

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

Est-ce incompatible avec la recommandation d'espaces autour de chaque autre occurrence de = en 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)

Tout lien vers une discussion/explication par Python's BDFL sera apprécié.

Attention, cette question concerne plus les kwargs que les valeurs par défaut, je viens d'utiliser le phrasé de PEP 8.

Je ne sollicite pas d'opinions. Je demande les raisons de cette décision. C'est plus comme demander pourquoi devrais-je utiliser { sur la même ligne que l'instruction if dans un programme C, pas si je dois l'utiliser ou non.

pythoncoding-stylepep8
90
soulcheck

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'affecter une variable à un argument de mot-clé nommé exactement de la même manière, ce qui améliore la lisibilité pour les voir sans espaces. Il est plus facile de reconnaître que nous utilisons des arguments de mots clés et ne nous assignons pas de variable.

En outre, les paramètres ont tendance à aller sur la même ligne alors que les affectations sont généralement chacune dans leur propre ligne, donc économiser de l'espace est probablement une question importante.

63
fortran

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 ceci:

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

De plus, cela n'a pas beaucoup de sens 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 tout en majuscules, descriptifs mais aussi courts que possible. Donc pas d'autre_très _...

12
rplnt

L'OMI laissant de côté les espaces pour args fournit un regroupement visuel plus propre des paires arg/valeur; il semble moins encombré.

8
JoeC

Il y a des avantages et des inconvénients.

Je n'aime pas beaucoup la façon dont le code compatible PEP8 se lit. Je n'accepte pas l'argument selon lequel very_long_variable_name=another_very_long_variable_name peut être plus lisible par 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 mise en évidence de la syntaxe.

Il y a cependant un avantage significatif. Si les règles d'espacement sont respectées, cela rend la recherche de paramètres exclusivement à l'aide d'outils beaucoup plus efficace.

8
Hywel Thomas

Je pense qu'il y a plusieurs raisons à cela, bien que je puisse simplement rationaliser:

  1. Il économise de l'espace, permettant à plus de définitions de fonctions et d'appels de tenir sur une seule ligne et économisant plus d'espace pour les noms d'argument eux-mêmes.
  2. En joignant chaque mot-clé et valeur, vous pouvez plus facilement séparer les différents arguments par l'espace après la virgule. Cela signifie que vous pouvez rapidement consulter le nombre d'arguments que vous avez fournis.
  3. La syntaxe est alors distincte des affectations de variables, qui peuvent avoir le même nom.
  4. De plus, la syntaxe est (encore plus) distincte des contrôles d'égalité a == b qui peut également être des expressions valides dans un appel.
3
otus

Pour moi, cela rend le code plus lisible et 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 fonction est qu'il ne devrait y avoir qu'un seul = Sur une ligne pour le premier, alors qu'en général il y a plusieurs = Sur une ligne pour ce dernier.

S'il n'y avait pas d'autres considérations, nous préférerions foo = 42 À foo=42, Car ce dernier n'est pas la façon dont les signes égaux sont généralement formatés, et parce que le premier sépare visuellement la variable et la valeur avec des espaces.

Mais lorsqu'il y a plusieurs affectations sur une ligne, nous préférons f(foo=42, bar=43, baz=44) à f(foo = 42, bar = 43, baz = 44), car la première sépare visuellement les différentes affectations avec des espaces, tandis que la seconde ne le fait pas, ce qui la rend un peu plus difficile pour voir où se trouvent les paires mot-clé/valeur.

Voici une autre façon de le dire: il y a is 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 via les espaces. Les niveaux de séparation inférieurs ne le sont pas (car ils seraient confondus avec les espaces blancs séparant le niveau supérieur). Pour l'affectation des variables, le niveau de séparation le plus élevé se situe entre la variable et la valeur. Pour l'affectation des mots clés de fonction, le niveau de séparation le plus élevé se situe entre les affectations individuelles elles-mêmes.

1
Denziloe