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


103

Pourquoi PEP 8 recommande-= t-il de ne pas avoir d'espaces 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 =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)

Tout lien vers une discussion / explication par le BDFL de Python sera apprécié.

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

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

Réponses:


72

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 le même, 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 que nous ne nous assignons pas de variable.

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


6
cela pourrait être le cas, mais cela semble toujours étrange d'introduire cette iconicité de l'OMI dans les recommandations de style de code pour un langage aussi bien conçu, uniquement pour enregistrer 2 caractères. C'est comme si le style de code java disait qu'il est préférable de mettre {une nouvelle ligne après if(enregistre le même nombre de caractères) mais pas dans la définition de classe. De plus, un paramètre de mot-clé est différent de la valeur par défaut mais utilise toujours la même recommandation de style.
soulcheck

3
Comme je l'ai dit, ce sont des choses différentes. Il est logique de les écrire différemment.
fortran

6
Je dirais que ce n'est pas vraiment plus lisible que kw1 = kw1, kw2 = kw2;) mais c'est peut-être ce que pensaient Guido et Barry.
soulcheck

1
J'accepterai cette réponse car elle est assez convaincante. cela ne me dérangerait pas qu'un lien le confirme
soulcheck

5
Le fait que l'argument de mot-clé soit fondamentalement différent de l'affectation de variable n'est pas un argument valable pour avoir des conventions différentes IMO, car la différence est déjà claire du contexte. Le premier se produit dans un appel de fonction, et le second doit être autonome au niveau d'indentation actuel. IMO, pour les noms de variables de plus de 5 à 6 caractères (c'est-à-dire la vraie vie pour la plupart), la variante avec des espaces est sans conteste plus lisible.
Axel

13

Je n'utiliserais pas very_long_variable_name comme argument par défaut. Alors considérez 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')

En outre, il n'est pas très logique d'utiliser des variables comme valeurs par défaut. Peut-être des 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 d'autre_très _...


1
ce sont des arguments de mots clés, un exemple similaire est dans PEP je l'ai seulement rendu moins lisible
soulcheck

3
Vous dites (essentiellement): pour rendre la règle sans espace raisonnable, écrivez des noms de variables très courts. Mais SI on a des noms de variables longs, alors la règle sans espace crée un environnement encombré. L'argument selon lequel `` ce n'est pas une affectation, donc ce sont des choses différentes '' ne me convient pas, car je me soucie plus de la lisibilité que de la sémantique et parce que si ce n'est pas une `` valeur par défaut pour une affectation '', alors qu'est-ce que c'est il?
PatrickT

1
@PatrickT L'argument "ce n'est pas une affectation, donc ce sont des choses différentes" ne fait rien pour expliquer pourquoi c'est (une notion philosophique); Cela explique simplement pourquoi cela peut être (une notion syntaxique).
Mateen Ulhaq

11

Il y a des avantages et des inconvénients.

Je n'aime pas du tout la lecture du code conforme à PEP8. Je n'accepte pas l'argument qui very_long_variable_name=another_very_long_variable_namepeut jamais être plus lisible par l'homme 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, notamment en l'absence de coloration syntaxique.

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.


Eh bien, si vous adhérez à la mise en place d'espaces =, la recherche à l'aide d'outils ne devrait pas être différente.
NoName

10

IMO laissant de côté les espaces pour args fournit un regroupement visuel plus clair des paires arg / valeur; ça a l'air moins encombré.


J'aime généralement les espaces, à tel point que j'ai tendance à mettre des espaces juste à l'intérieur des parenthèses afin que tous les paramètres soient entourés d'espace. Mais je pense que le arg1=40est plus lisible car la relation est plus évidente.
Charlie Gorichanaz

3

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

  1. Cela économise de l'espace, permettant à plus de définitions de fonctions et d'appels de tenir sur une ligne et d'économiser plus d'espace pour les noms d'arguments eux-mêmes.
  2. En joignant chaque mot-clé et valeur, vous pouvez séparer plus facilement les différents arguments par l'espace après la virgule. Cela signifie que vous pouvez rapidement observer 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 vérifications d'égalité a == bqui peuvent également être des expressions valides dans un appel.

3

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 attributions de variables et les attributions de mots-clés de fonction est qu'il ne devrait y avoir qu'un seul =sur une ligne pour le premier, alors qu'il y a généralement plusieurs =s sur une ligne pour le second.

S'il n'y avait pas d'autres considérations, nous préférerions le foo = 42faire 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 par des espaces.

Mais quand il y a plusieurs affectations sur une ligne, nous préférons le f(foo=42, bar=43, baz=44)faire f(foo = 42, bar = 43, baz = 44), car la première sépare visuellement les différentes affectations avec des espaces, alors que la seconde 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 le dire: il y a une cohérence derrière la convention. Cette cohérence est la suivante: le "niveau de séparation le plus élevé" est rendu visuellement plus clair via des espaces. Les niveaux inférieurs de séparation ne le sont pas (car 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'attribution de mots clés de fonction, le niveau de séparation le plus élevé se situe entre les affectations individuelles elles-mêmes.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.