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

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.

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.

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 _...

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.

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é.

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.

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.