Style correct pour les sauts de ligne lors de l'enchaînement de méthodes en Python

Question

J'ai un code comme celui-ci. La rupture doit-elle intervenir avant ou après les points ?

# before
my_var = somethinglikethis.where(we=do_things).where(we=domore).where(we=everdomore)

# this way
my_var = somethinglikethis.where(we=do_things) \
                          .where(we=domore) \
                          .where(we=everdomore)

# or this way
my_var = somethinglikethis.where(we=do_things). \
                           where(we=domore). \
                           where(we=everdomore)

Answer 1

PEP 8 recommande d'utiliser des parenthèses afin de ne pas avoir besoin de \ et suggère gentiment de casser antes de opérateurs binaires au lieu de les suivre. Ainsi, la meilleure façon de formater votre code est la suivante :

my_var = (somethinglikethis
          .where(we=do_things)
          .where(we=domore)
          .where(we=everdomore))

Les deux passages pertinents sont celui-ci, tiré du Longueur maximale de la ligne section :

La meilleure façon d'envelopper les longues lignes est d'utiliser la continuation de ligne implicite de Python à l'intérieur des parenthèses, des crochets et des accolades. Les longues lignes peuvent être réparties sur plusieurs lignes en mettant les expressions entre parenthèses. Celles-ci doivent être utilisées de préférence à l'utilisation d'une barre oblique inverse pour la continuation de la ligne.

... et l'ensemble du Une ligne doit-elle être coupée avant ou après un opérateur binaire ? section :

Une ligne doit-elle être coupée avant ou après un opérateur binaire ?

Pendant des décennies, le style recommandé était de rompre après les opérateurs binaires. Mais cela peut nuire à la lisibilité de deux façons : les opérateurs ont tendance à être éparpillés sur différentes colonnes de l'écran, et chaque opérateur est et chaque opérateur est déplacé de son opérande à la ligne précédente. Dans ce cas, l'œil l'œil doit faire un travail supplémentaire pour savoir quels éléments sont ajoutés et quels éléments sont soustraits. soustraits :

# No: operators sit far away from their operands
income = (gross_wages +
          taxable_interest +
          (dividends - qualified_dividends) -
          ira_deduction -
          student_loan_interest)

Pour résoudre ce problème de lisibilité, les mathématiciens et leurs éditeurs suivent la convention inverse. Donald Knuth explique la règle traditionnelle règle dans son Ordinateurs et composition série : "Bien que les formules dans un paragraphe s'interrompent toujours après les opérations binaires et les relations, les formules affichées s'interrompent toujours avant les opérations binaires".

Si l'on suit la tradition des mathématiques, on obtient généralement plus code plus lisible :

# Yes: easy to match operators with operands
income = (gross_wages
          + taxable_interest
          + (dividends - qualified_dividends)
          - ira_deduction
          - student_loan_interest)

Dans le code Python, il est permis de casser avant ou après un opérateur binaire tant que la convention est cohérente au niveau local. Pour le nouveau code, le style de Knuth est suggéré.

Notez que, comme indiqué dans la citation ci-dessus, PEP 8 utilisé pour donner le conseil inverse sur la façon de contourner un opérateur, cité ci-dessous pour la postérité :

La meilleure façon d'envelopper les longues lignes est d'utiliser la ligne implicite de Python. implicite de Python à l'intérieur des parenthèses, des crochets et des accolades. Les longues lignes peuvent être être réparties sur plusieurs lignes en plaçant les expressions entre parenthèses. Ces doivent être utilisées de préférence à l'utilisation d'un backslash pour la continuation de la ligne. Veillez à indenter la ligne poursuivie de manière appropriée. L'endroit préféré pour entourer un opérateur binaire est après l'opérateur, pas avant. Quelques exemples :

class Rectangle(Blob):

    def __init__(self, width, height,
                 color='black', emphasis=None, highlight=0):
        if (width == 0 and height == 0 and
            color == 'red' and emphasis == 'strong' or
            highlight > 100):
            raise ValueError("sorry, you lose")
        if width == 0 and height == 0 and (color == 'red' or
                                           emphasis is None):
            raise ValueError("I don't think so -- values are %s, %s" %
                             (width, height))
        Blob.__init__(self, width, height,
                      color, emphasis, highlight)

Answer 2

La PEP 8 indique que la rupture avant l'opérateur est préférable :

Donald Knuth explique la règle traditionnelle dans sa série Computers and Typesetting : "Bien que les formules à l'intérieur d'un paragraphe s'interrompent toujours après les opérations binaires et les relations, les formules affichées s'interrompent toujours avant les opérations binaires".

...

Dans le code Python, il est permis de casser avant ou après un opérateur binaire, tant que la convention est cohérente localement. Pour un nouveau code, le style de Knuth est suggéré.

https://www.python.org/dev/peps/pep-0008/#should-a-line-break-before-or-after-a-binary-operator

Answer 3

Faites ce qui fonctionne.

Consultez également ce livre blanc sur le mythes de l'indentation en Python. Cela peut être trouvé aquí .

Ça commence par :

"Les espaces blancs sont importants dans le code source Python."

Non, pas en général. Seul le niveau d'indentation de vos instructions est significatif (c'est-à-dire les espaces à l'extrême gauche de vos déclarations). Partout ailleurs, les espaces ne sont pas significatifs et peuvent être utilisés comme comme vous le souhaitez, comme dans n'importe quel autre langage. Vous pouvez également insérer des lignes vides qui ne contiennent rien (ou seulement des espaces arbitraires) n'importe où.

J'espère que cela vous aidera.

Answer 4

POUR INFO, autopep8 (avec un --aggressive flag) a produit ceci à partir de votre code original :

my_var = somethinglikethis.where(
    we=do_things).where(
    we=domore).where(
    we=everdomore)

Mais je suis d'accord : la solution de Bastien est plus élégante.

Answer 5

Il n'y a vraiment pas de mauvaises voies là-dedans. Toutes celles que vous avez énumérées fonctionnent de la même manière.