Le 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 vérification de mon style de codage avec pep8 plugin pour vimj'ai reçu cet avertissement:

missing whitespace around operator

Il semble que pour être en conformité avec la PEP 8 je devrais plutôt écrire ceci?

some_list = range(a, b + 1)

Mais j'ai lu PEP 8 - Guide de Style pour le Code Python à plusieurs reprises et juste ne pouvez pas trouver la règle soit appliquée à l'avertissement ci-dessus.

Donc, je veux savoir: lors de l'utilisation de la PEP-8 style, est l'espace nécessaire autour des opérateurs(+,-,*,/,etc) en fonction des arguments?

source d'informationauteur wxl24life

  1. 12

    http://www.python.org/dev/peps/pep-0008/#other-recommendations

    Toujours entourent ces opérateurs binaires avec un seul espace de chaque côté: affectation (=), augmentée d'affectation ( + = , -=, etc.), les comparaisons (==, <, >, !=, <>, <=, >=, dans, pas, est, ne l'est pas), les Booléens (et, ou, non).

    L'exception, c'est quand = est utilisé pour définir les paramètres nommés.

    Edit:

    J'ai regardé le code source de Python standard library et a trouvé une occurrence du scénario présenté ci-dessus:

    http://hg.python.org/cpython/file/9ddc63c039ba/Lib/json/decoder.py#l203

                end = _w(s, end + 1).end()
  2. 33

    Votre plugin Vim a été mal quand vous avez demandé en 2013... mais en 2010, quand il a été rédigé. PEP 8 a a changé à plusieurs repriseset la réponse à votre question a été modifiée.

    À l'origine, la PEP 8 contient le membre de phrase:

    Utilisation des espaces autour des opérateurs arithmétiques

    Sous que règle,

    range(a, b+1)

    est clairement mauvais et devrait être écrit comme 

    range(a, b + 1)

    C'est la règle que pycodestyle (le Python linter, précédemment connu sous le pep8.py que le demandeur est Plugin Vim utilise sous le capot), mis en œuvre depuis plusieurs années.

    Cependant, cela a été changé en avril 2012. La simplicité de la langue qui a laissé aucune marge d'appréciation a été remplacé avec ce beaucoup plus laineuse conseils:

    Si les opérateurs avec des priorités différentes sont utilisées, envisager d'ajouter les espaces autour des opérateurs avec la priorité la plus faible(s). Utilisez votre propre jugement; toutefois, n'utilisez jamais plus d'un espace, et d'avoir toujours la même quantité d'espace blanc sur les deux côtés d'un opérateur binaire.

    Point de prêter à confusion, les exemples qui illustrent cette règle ont été à l'origine reste inchangé (et donc en contradiction avec la prose). C'était finalement fixe, mais pas très bienet les exemples sont encore confus, semble sous-entendre une beaucoup plus strict et moins subjective de la règle que la prose n'.

    Il y a toujours une règle exigeant que les espaces autour du certains opérateurs:

    Toujours entourent ces opérateurs binaires avec un seul espace de chaque côté: affectation ( = ), augmentée d'affectation ( += , -= etc.), comparaisons ( == , < , > , != , <> , <= , >= , in , not in , is , is not ), les Booléens ( and , or , not ).

    mais notez que cette règle explicite sur les opérateurs, il se réfère et des opérateurs arithmétiques comme + sont pas dans la liste.

    Ainsi, le PEP, dans sa forme actuelle, ne pas dicter si oui ou non vous devez utiliser des espaces autour de la + opérateur (ou d'autres opérateurs arithmétiques comme * et / et **). Vous êtes libre de "utilisez votre propre jugement".

    Par le chemin, la pycodestyle linter a changé son comportement à la fin de 2012 afin de refléter le changement dans le PEPen séparant les règles sur l'utilisation des espaces autour des opérateurs dans les deux codes d'erreur, E225 (pour les non-utilisation des espaces autour des opérateurs de la PEP 8 encore nécessite l'espace autour d'), qui est activé par défaut, et E226 (pour les non-utilisation des espaces autour des opérateurs arithmétiques), qui est ignoré par défaut. La question que personne ici ne l'ai utilisé un peu ancienne version de la linter quand il a posé cette question en 2013, compte tenu de l'erreur qu'il a vu.