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

J'estime personnellement qu'un seul espace avant et après TOUS les opérateurs d'affectation = devrait être standard quel que soit le langage de programmation/marquage, parce que il aide l'œil à différencier les jetons de différents canaux (c'est-à-dire isoler un jeton de nom de variable/paramètre d'un jeton d'opérateur d'affectation) = à partir d'un jeton de valeur ou d'une séquence de jetons de valeur d'expression).

Il n'est ni lisible ni intuitif de regrouper trois jetons de trois canaux différents en un seul jeton "parameter-name-assignment-operator-value/expression-tuple".

Prenons l'exemple des jetons non délimités :

def my_func(par1: str, par2: str):
    print('%s %s' % (par1, par2))

cond = 'conditional string'
my_func(par1='string with a lot of spaces',
        par2=cond if cond is not None else 'no string')

Accordée, la valeur transmise à par2 devrait probablement être stockée dans une variable plutôt que d'être transmise sous forme d'expression "ternaire"...

par2 = cond if cond is not None else 'no string'
my_func(par1='string with a lot of spaces', 
        par2=par2)

...mais si nous décidons quand même d'utiliser l'expression ternaire, je trouve que l'ajout des espaces de délimitation avant et après les opérateurs d'affectation est plus lisible, presque comme un objet dictionnaire (ce que les séquences de paramètres python sont fondamentalement) :

my_func(par1 = 'string with a lot of spaces', 
        par2 = cond if cond is not None else 'no string')
# OR
par2 = cond if cond is not None else 'no string'
my_func(par1 = 'string with a lot of spaces', 
        par2 = par2)

Answer 2

Je pense qu'il y a plusieurs raisons à cela, même si je ne fais peut-être que rationaliser :

1. Elle permet d'économiser de l'espace, en faisant tenir plus de définitions et d'appels de fonctions sur une seule ligne et en économisant de l'espace pour les noms d'arguments eux-mêmes.
2. En joignant chaque mot-clé et chaque valeur, vous pouvez plus facilement séparer les différents arguments par l'espace après la virgule. Cela signifie que vous pouvez rapidement vérifier le nombre d'arguments que vous avez fournis.
3. La syntaxe est alors distincte des affectations de variables, qui peuvent porter le même nom.
4. En outre, la syntaxe est (encore plus) distincte des contrôles d'égalité a == b qui peuvent également être des expressions valables à l'intérieur d'un appel.