PEP 8 nécessite-t-il des espaces autour des opérateurs dans les arguments de fonction?
J'ai ce code:
some_list = range(a, b+1)
Après avoir vérifié mon style de codage avec plugin pep8 pour vim , j'ai reçu cet avertissement:
missing whitespace around operator
Il semble que pour être conforme à PEP 8, je devrais plutôt écrire ceci?
some_list = range(a, b + 1)
Mais j'ai lu PEP 8 - Guide de style pour Python Code plusieurs fois et je ne trouve tout simplement pas la règle appliquée à l'avertissement ci-dessus.
Je veux donc savoir: lors de l'utilisation du style PEP-8, des espaces sont-ils nécessaires autour des opérateurs (+, -, *, /, etc.) dans les arguments d'une fonction?
http://www.python.org/dev/peps/pep-0008/#other-recommendations
Entourez toujours ces opérateurs binaires d'un seul espace de chaque côté: affectation (=), affectation augmentée (+ =, - = etc.), comparaisons (==, <,>,! =, <>, <=,> = , in, not in, is, is not), Booleans (and, or, not).
L'exception à cela est lorsque = est utilisé pour définir les paramètres nommés.
Éditer:
J'ai parcouru le code source de la bibliothèque standard de Python et trouvé une occurrence du scénario présenté ci-dessus:
http://hg.python.org/cpython/file/9ddc63c039ba/Lib/json/decoder.py#l2
end = _w(s, end + 1).end()
Votre plugin Vim était faux quand vous l'avez demandé en 2013 ... mais juste en 2010, quand il a été créé. PEP 8 a changé à plusieurs reprises , et la réponse à votre question a également changé.
À l'origine, le PEP 8 contenait la phrase:
Utiliser des espaces autour des opérateurs arithmétiques
Sous cette règle ,
range(a, b+1)
est sans équivoque erroné et doit être écrit comme
range(a, b + 1)
C'est la règle que pycodestyle (le linter Python, précédemment connu sous le nom de pep8.py) que le demandeur plugin Vim utilise sous le capot ) mis en œuvre depuis plusieurs années.
Cependant, cela a été changé en avril 2012. Le langage simple qui ne laissait aucune place à la discrétion a été remplacé par ce conseil beaucoup plus lâche:
Si des opérateurs avec des priorités différentes sont utilisés, pensez à ajouter des espaces autour des opérateurs avec la ou les priorités les plus faibles. Utilisez votre propre jugement; cependant, n'utilisez jamais plus d'un espace et ayez toujours la même quantité d'espace blanc des deux côtés d'un opérateur binaire.
Confusément, les exemples qui illustrent cette règle sont restés à l'origine inchangés (et donc en contradiction avec la prose). C'était finalement corrigé, mais pas très bien , et les exemples restent confus, semblant impliquer une règle beaucoup plus stricte et moins subjective que la prose.
Il existe toujours une règle exigeant des espaces autour de certains opérateurs particuliers :
Entourez toujours ces opérateurs binaires d'un seul espace de chaque côté: affectation (
=), affectation augmentée (+=,-=etc.), des comparaisons (==,<,>,!=,<>,<=,>=,in,not in,is,is not), Booléens (and,or,not).
mais notez que cette règle est explicite sur les opérateurs auxquels elle se réfère et les opérateurs arithmétiques comme + ne sont pas pas dans la liste.
Ainsi, le PEP, dans sa forme actuelle, ne dicte pas si vous devez ou non utiliser des espaces autour du + opérateur (ou d'autres opérateurs arithmétiques comme * et / et **). Vous êtes libre de "utiliser votre propre jugement" .
Soit dit en passant, le linter pycodestyle a changé son comportement à la fin de 2012 pour refléter le changement dans le PEP , séparant les règles d'utilisation des espaces autour des opérateurs en deux codes d'erreur, E225 (pour l'échec de l'utilisation des espaces autour du les opérateurs que PEP 8 utilise toujours nécessite des espaces autour), qui est activé par défaut, et E226 (pour l'échec de l'utilisation des espaces autour des opérateurs arithmétiques), qui est ignoré par défaut. Le demandeur de questions ici doit avoir utilisé une version légèrement dépassée du linter lorsqu'il a posé cette question en 2013, compte tenu de l'erreur qu'il a vue.
Pour les opérateurs arithmétiques, je mets généralement des espaces autour de + et - mais pas dans *, ** et /. Voici un exemple:
(...)
alpha__w = (wave__w - central_w_par*doppler_factor)/sig_par
e1__w = np.exp(-.5*(alpha__w**2))
Y1__w = norm*e1__w/(sig_par*(2*np.pi)**.5)
(...)